attack-surface/management

10 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Attack Surface expansion from deployment practices

Deploying multiple versions of an application, leaving unused features in case they may be needed later, or leaving old backup copies and unused code increases the Attack Surface. Source code control and robust change management/configuration practices should ensure the deployed Attack Surface matches the theoretical one.

Backup security as part of Attack Surface

Backups of code and data (online and offline media) are an important but often ignored part of a system's Attack Surface. Protecting data and IP through secure software and hardened infrastructure is wasted if backups are not protected.

Attack Surface changes requiring risk assessment review

When adding new features or functionality, determine: What has changed? What is being done differently (technology, approach)? What security holes could have been opened? Changes to session management, authentication, password management, authorization and access control, encryption and secrets handling, data validation, and architectural layering or trust relationships all require threat assessment.

Risk assessment for similar incremental changes

If a new endpoint follows the same design and uses the same technology as existing endpoints, it requires similar security testing and review. Adding another field to an existing page or another similar web page has not meaningfully increased the risk profile unless a new design or framework is being used.

Attack Surface assessment in different development methodologies

Attack Surface threat and risk assessment can be done periodically in phased/spiral/waterfall development, or continuously and incrementally in Agile/iterative development approaches.

Attack Surface reduction strategies

Application Attack Surface typically increases over time as interfaces and user types are added. Reduce Attack Surface by: simplifying the model (reducing user levels or not storing unneeded confidential data), turning off unused features and interfaces, introducing operational controls like Web Application Firewalls (WAF), and implementing real-time application-specific attack detection.

Legacy application inventory documentation

Start by compiling documentation identifying the legacy applications used by the organization including version numbers, date of production, and relevant configuration settings. Ideally, this will include details regarding what network hosts need to be situated on to reach the application and associated infrastructure. A record of the services running on infrastructure used for hosting the application and/or for data storage should also be outlined. In some circumstances documentation could include information about the physical location of and permitted access to servers associated with the application. Organizations might opt to generate a formal SBOM (Software Bill of Materials).

Container supply chain security best practices

Best practices for securing the container supply chain include: use trusted base images from reputable sources to reduce vulnerabilities; implement image scanning with tools like Clair, Trivy, or Aqua Security; secure CI/CD pipelines with proper access controls and monitoring; sign and verify images using Notary or Cosign; use private registries with access controls; monitor continuously for vulnerabilities in dependencies and base images; implement runtime security tools to detect anomalies.

Disable unused API routes to reduce attack surface

Remove all unused routes and API endpoints from Node.js applications to minimize attack surface. Some frameworks like Sails and Feathers automatically generate REST API endpoints. If a URL does not match a custom route, it may match an automatic route and generate a response, leading to information leakage or arbitrary command execution. Know which routes frameworks auto-generate and disable the ones not needed.

Rails restrictive routes configuration

Avoid catch-all routes like match ':controller(/:action(/:id(.:format)))' which expose any public method on any controller. Define specific routes in config/routes.rb to control which controller methods are accessible and how they can be reached.

Give your agent this brain