HomeDocumentationCode SamplesAnnouncementsModelsRelease NotesFAQVideos
Developer HubAPI StatusSupport
Documentation
Developer HubAPI StatusSupport

Vulnerability Management

Develop effective vulnerability practices.

Overview

This technical paper covers different vulnerability management practices such as vulnerability scans, penetration tests, and code vulnerability scans. This paper will also explore processes to restore availability and access after a service interruption due to an incident.

Data Protection Policy (DPP) requirements

As part of Amazon’s Data Protection Policy (DPP) (DPP), developers have to implement vulnerability scans at minimum semi-annually, penetration tests yearly, code vulnerability scans prior to release of new code, features, or products, and to ensure they can restore availability and access to Personal Identifiable Information (PII) within hours. This is to avoid exposure of sensitive data, including PII. Every SP-API developer needs to ensure that vulnerable points such as public-facing websites, interfaces, servers, and new features have the expected level of security and protection even before release.

Vulnerability Management

Developers must create and maintain a plan or run-book to detect and remediate vulnerabilities. Developers must protect physical hardware containing PII from technical vulnerabilities by performing vulnerability scans and remediating appropriately. Developers must conduct vulnerability scanning at least every 180 days, penetration test at least every 365 days, and scan code for vulnerabilities prior to each release. Furthermore, developers must control changes to the storage hardware by testing, verifying changes, approving changes, and restricting access to who can perform those actions. Developers must have appropriate procedures and plans to restore availability and access to PII in a timely manner in the event of a physical or technical incident.

Vulnerability scans

A vulnerability scan is the process of identifying, discovering, analyzing, and reporting host access, weaknesses, and network gaps for instances or software that the application is running.

It is essential in terms of security to verify that public facing devices/instances are protected against bad actors. In an ideal scenario, scans can be run by vulnerability scanner tools to identify/classify risk factors, and possible attack vectors within the network (including software and hardware assets).

Here are the top ten vulnerabilities according to the Open Web Application Security Project (OWASP) for 2021 and associated Common Weakness Enumerations (CWE):

CWEVulnerability PointBrief Description
A01Broken access controlUser performs an action they are not supposed to be able to access.
A02Cryptographic failuresLack of or weak cryptographic practices.
A03InjectionHackers are able to insert data and manipulate it within a network.
A04Insecure designLack of planning during the network design stage.
A05Security micro-configurationsSecurity settings in databases, libraries, or servers not set, which could lead to a vulnerability.
A06Vulnerable and outdated componentsLegacy or unsupported versions of software or an operating system.
A07Identification and authentication failuresLack of user access controls and credential management.
A08Software and data integrity failuresNo protection against integrity violations.
A09Secure logging and monitoring failureNo monitoring service making it difficult to identify breaches and outgoing attacks.
A10Server-side request forgery (SSFR)Unverified URL supplied by a user which coerces an application to send requests that bypass network security.

Refer to OWASP – Vulnerability Scanning Tools for a list of free and paid scanning tools.

After the scans are complete, developers have to prioritize vulnerabilities according to the level of security impact and work to remediate those accordingly.

  • External vulnerability scans: External scans are meant to check vulnerabilities in external/public points such as ports, websites, networks, and applications.

  • Internal vulnerability scans: Internal scans give visibility on possible security gaps within a private network.

  • Intrusive and non-intrusive scans: Non-intrusive scans will scan a specific target such as network traffic or a database's version, but it does not affect service levels as it only checks the information without taking advantage of the vulnerability. An intrusive scan is meant to exploit the vulnerability at its highest level and provide more insight about the vulnerabilities found, but it also interrupts service levels, so use it in a controlled environment.

Amazon Inspector

Amazon Inspector is a scalable vulnerability management tool which scans workloads and unintended network exposures to verify that there are no vulnerabilities in operating systems running EC2 instances.

Amazon Inspector provides near real-time vulnerability finding reports using updated Common Vulnerabilities and Exposure (CVE) factors and checking different coding languages such as Java, Python, and Node.js. Developers that use Amazon Inspector can use it for compliance validation of programs such as PCI, ISO, and CSA STAR certificates.

The Amazon Inspector architecture.

Amazon Guard

Amazon’s Security team developed Amazon’s SP-API-Guard as an application that runs in AWS instances to check and asses security compliance with Amazon’s DPP. SP-API Guard also provides a recommendation report of any security gap it finds within a day to an S3 bucket. This reduces the effort for manual Data Security Assessments and remediation plan times while providing recommended solutions for vulnerabilities found.

The Amazon Guard architecture.

Penetration testing

Penetration testing (pen testing) is a way to check in a simulated/controlled environment for any vulnerabilities in different points of applications or networks. This is done to confirm which vulnerabilities can be exploited by bad actors.

Pen testing consists of the following stages:

  • Planning Stage: The team sets goals and the scope for the testers' pen tests. All parties must be aware of the upcoming tests.

  • Scan/Discovery Stage: Pen testers initiate the process of network recognition and code inspection.

  • Penetration Stage: The pen tester attempts to gain access to the network/instances using different types of attacks such as SQL injection, cross-site scripting, and backdoors to exploit vulnerabilities.

  • Analysis/Report Stage: The pen tester creates a report with detailed information about actions taken to penetrate network security and the vulnerabilities found. The pen tester must include a recommended actions section in the report.

  • Remediation/Clean up Stage: The responsible team takes the lead and starts work on remediating vulnerabilities reported after the pen tests are completed.

As an extra security step to ensure that vulnerabilities are remediated or patched, developers run a second test after the remediation stage to ensure there is no item that was left behind or unattended.

OWASP also offers a penetration test guide (OWASP ZAP) for developers who want to know more on how to apply pen tests at an application level and for their network components such as firewalls and ports.

Code vulnerability scans

Code vulnerability scans are intended to reduce risks when a new feature/product is being released. Developers can ensure there are no errors, technical issues, or security gaps when the code is deployed with the use of the following code scanning tools:

  • Static Application Security Test (SAST): Review of the code without having to run the code. SAST checks how the code is written to point out any security issues in it.

  • Dynamic Application Security Test (DAST): In contrast to SAST, DAST checks the code in a running application by simulating attacks with malicious payload injections. DAST helps developers to identify vulnerabilities within a running application.

  • Interactive Application Test (IAST): IAST checks application functionalities across testing environments. This facilitates implementation and scalability as it helps to reduce possible downtime or service interruptions by tackling vulnerabilities prior to release.

These tools must follow the standards given by OWASP to check the application security against the top ten security risks. Developers have to proceed with scanning code to identify, classify, and prioritize any security flaws that affect or interrupt service after the product is launched.

Disaster recovery plan

To ensure that application users are not affected by incidents (technical or physical) developers must have a plan that covers actions on how to restore availability and access to PII data in a short time, taking in consideration Recovery Time Objective (RTO) and Recovery Point Objective (RPO). AWS offers guidance in Establishing RTO and RPO Targets for Cloud Applications.

  • RTO: The time it takes the developers to restore normal service levels to application users. This can be accomplished by having redundancy within network instances/services that are critical for the application's functionality.

  • RPO: The point in time where developers can restore the data, in other words, how much data is acceptable to loss after an incident. A fundamental aspect of this objective is to have one or more backups of the data in different locations, and perform those backups twice a week if possible.

Developers are expected to use recovery strategies and test them to meet objectives (RTO and RPO). AWS Resilience Hub is an AWS service that helps to establish RTO and RPO targets, and it analyzes applications against those targets.

Conclusion

Vulnerability management is an essential security standard. Vulnerability scans and penetration tests help to identify and reduce possible risks within a network environment and application instances. Developers have to run vulnerability scans and pen tests at least once a year in accordance to DPP requirements. The practice of conducting these assessments helps developers to increase their security maturity and comply with standards that they can face, such as regulatory or industry best practices.

Developers must run a code scan prior to the release of features or products. Testing must be done in an isolated and controlled environment to ensure that there are no security gaps for new releases and no data is exposed.

Having backups, snapshots, or images helps to reduce the impact of losing PII data due to an incident. Ensuring resilience for your application services reduces the time it takes you to restore access and availability to PII data.