Activity 7.1: Review an Application Using the OWASP Attack Surface Analysis Cheat Sheet

In this excercise I will review an application against the OWASP Attack Surface Analysis Cheat Sheet.

Cheat Sheet Summary

The OWASP Attack Surface Analysis sheet focuses on documenting all externally vulnerable aspects of a system to protect it from attack. This analysis may omit internal or insider attacks since these forms of attack may require a seperate analysis. After the analysis, areas of a network which need to additional controls or testing are identified.

OWASP describes the attack surface for an application as:

  • Sum of all paths for data/commands into and out of the application, and the code that protects these paths.
  • All valuable data used in the application, including secrets and keys, intellectual property, critical business data, personal data and PII.
  • The code that protects this data (including encryption and checksums, access auditing, and data integrity and operational security controls).

The OWASP approach also reccommends grouping each type of attack point into buckets or categories based on risk:

  • External (or Internal)
  • Purpose
  • Implementaiton
  • Design
  • Technology

In order to map vulnerable parts of the application which are accessible over the web, the following web app testing tools can be used:

These tools will allow you to map entries points such as User interface (UI) forms and fields, HTTP headers and cookies, APIs, files, databases, local storage, email, messaging, runtime arguements and more.

Two final important points areas to consider when developing conclusions are backups and an application’s attack surface growing over time. Backups of code, data and infraastructure are essential for a quick recovery in the event of any attack. Ideally multiple backups should be available, both online and offline. Second, application attack surfaces often increase over time. Proactive audits over time should be used to identify exposed parts of an application which are no longer used and can be removed.

Building the Web App

For this excercise, I chose to not only analyze an app but also build the app myself. As most modern web apps are build on the cloud… and that cloud is either AWS or Azure… I will be building the web app listed in this AWS project. Before the web app is deployed, I will perform a brief analysis of both the external and internal attack surfaces. After my analysis, I will run a scan using Arachni in order to compare my findings with the scan report.

The architecture is as follows: AWS Web App

Initial Analysis

Here is my analysis of the attack surface as presented by the diagram.

Attack Surface Vulnerable Aspects
External
  1. Cognito - Password forms vulnerable to brute force, mitm or injection attacks
  2. API GW - Exposed APIs vulnerable to abuse, injection attacks, etc.
  3. S3 Bucket - Ensure CORS policy is set, set bucket policy to limit API calls to storage.
  4. Cloud9 - AWS console access vulnerable to brute force, injection attacks, mitm credenetial hijacking.
  5. Network Load Balancer - Vulnerable to DOS attacks
Internal
  1. CodeCommit - Compromised users or users with high access can insert malicious code into the build.
  2. CodeBuild - Tests can be altered to allow malcious code into the build.
  3. DynamoDB - Data can be exfiltrated or altered by employees or compromised accounts.
  4. Lambda - Malicious code can be inserted into the Lambda function.
  5. Kinesis S3 - Data can be exfiltrated or altered by employees or compromised accounts.
  6. Fargate - Service can be disabled, deleted or used to exfiltrate incoming data.
  7. IAM - Users permissions or roles can be abused. Privelege escalation attacks my be possible.

Scan Results

Now I will run a scan using Arachni. Once Archani is installed, here are the basic steps you can follow:

  1. Navigate to Scans > New Archni Scan

  2. Enter URL of the website > Go! Arachni Scan

  3. Let the scan run. The scanner will perform several different across all pages on the web application. Arachni Scan

  4. Once the scan is finished it will list all the identified issues with the web application. Arachni Scan

Conclusions

Compared to the several possible vulnerabilites I identified, Arachni only flagged a five possible issues with the web application. The most serious issue being a password form using the HTTP protocol, not HTTPS. As TLS certificates can easily be added to a web application to enable HTTPS this is a minor issue. To develop a complete picture of the web application’s attack surface, I would test it with a range of different tools. As this analysis only used one tool, the full attack surface of the application cannot be verified.

Activity 7.2: Review a NIST Security Architecture

In this exercise I will review a NIST Security Architecture Diagram! Specifically, I will be looking at a diagram found in NIST SP1800-5b.

Here is the architecture which shows an example of an enterprise security architecture. Nist Diagram

Lets mark this diagram up! I will be paying extra close attention to areas where: 1. A single failure could be possible 2. Sections where I could apply additional controls Nist Diagram

Glossary

A glossary of all the terms, acronyms and slang I run across for this chapter.

Layered Security Approach where each layer has additional protections preventing a flaw in another layer from allowing an attacker access
Zero Trust Each action request and allowed must be verified before allowing to occur
Air Gap Ensuring there is not connection at all between infrastructure
SDN Software Defined Networking; Makes networks programmable and allows for central control of networks
Containerization Allows applications to run in their own isolated environments with their own required components
Asset Management Knowing what assets you and their current state
Active Defence Offensive actions taken to counter adversaries
Technical Controls Firewalls, IDS, IPS, network segmentation, auth and authorization systems.
Administrative Controls Processes and procedures, i.e. incident response plans, account management, change control, configuration management, policies, etc.
Physical Controls Include locks, fences and other controls to limit physical access
Preventive Controls Stops an incident from occurring by taking proactive measures
Detective Controls Detect an incident and capture info about it
Corrective Controls Remediate incidents and act to limit how much damage can result from the incident
Layered Host Security Applying the following controls on a host can allow layered security on an endpoint: strong passwords, mfa, host firewalls, data loss prevention, whitelisting or blacklisting apps, AV, Patch management, system hardening, encryption, file integrity monitoring, logging, monitoring
Sink holing Redirecting traffic from its original destination to the destination of your choice
Operational View View which shows how an architecture functions, what it performs and how information flows
Technical View View which focuses on the technical configuration of an architecture
Logical View View which describes how systems interconnect
CIP Continual Improvement Process
Data Loss Prevention System that scans outbound traffic and prevents it from being transmitted if it contains certain data types
NAC Network Access Control; System that validates systems and users before they connect to a network