Pen Testing Checklist for Cloud

Start with the Contract. Your Cloud services are provided under contract between you and your CSP. This forms the base of the relationship, and defines what activities each party is responsible to perform. Not all CSP’s are the same, nor are all contracts identical. Some will have various tiers of service, others may provide a base offering with additional “add-on” options. Whatever your situation, it is vital to have a clear understanding of R&R, policies, service commitments, and restrictions.

1. Check the Service Level Agreement (SLA) to ensure the appropriate Pen Test policy has been identified, and R&R clearly defined. In many cases, elements of Pen Testing are spread across multiple players such as the CSP and the client, so it is necessary to clearly document who does what, and when it is to be done.
2. Governance & Compliance requirements need to be understood. Factors need to include which party will be responsible to define, configure and validate security settings required to meet applicable regulatory controls for your business. This includes providing appropriate evidence for audits and inspections.
3. Security and Vulnerability Patching and general maintenance responsibilities and timeframes need to be documented. You as the client may have responsibility for maintaining your virtual images and resources, but the CSP will likely be accountable for the underlying physical hardware systems. Both need to be actively managed, along with all network and SAN equipment.
4. Computer access and Internet usage policies need to be clearly defined and properly implemented to ensure appropriate traffic is permitted while inappropriate traffic is denied at the perimeter.
5. Ensure all unused ports are disabled and unused protocols are either not installed or disabled and locked down to prevent unauthorized activation.
6. Data encryption while both in transit and at rest is becoming more common, but never assume. Ensure that encryption is either set as the default or that appropriate steps are implemented to ensure it is activated.
7. Verify that your requirements for Two Factor Authentication and One Time Passwords are implemented and actively securing network access. Check if your CSP permits any bypass scenarios.
8. SSL is only as good as the Certificate Authority (CA) that issued the certificates. Ensure SSL is active, and that a reputable CA stands behind the certificates.
9. Hold your CSP accountable and validate they are using appropriate security controls for physical and logical access to the data center and the infrastructure hardware with which they provide your services.
10. Know your CSP’s policy and procedures relative to data disclosure to third parties, both for unauthorized access and providing data when requested or subpoenaed by law enforcement.

More than just running a scan, Pen Testing requires an understanding your environment and the associated roles and responsibilities and even liabilities between you and your CSP.

PCI Pen Testing Requirements

Scanning Isn’t Testing

Requirement 11 is the juggernaut of PCI v3.2. It’s packed full of objectives involving network scanning (11.2) and penetration testing (11.3). Just because scanning and testing are lumped into the same PCI requirement, doesn’t mean they accomplish the same goals.

The PCI Standards Security Council is helping to clear the air with a couple of simple descriptions.
Vulnerability Scanning: Identifies, ranks, and reports on vulnerabilities that, if
exploited, may result in an intentional or unintentional compromise of a system. Translation? It’s an automated process taking a short amount of time, with no verification and very high chance of false-positives.
Penetration Testing: Identifies ways to exploit vulnerabilities to circumvent or defeat the security features of system components. Translation? It’s a manual or automated testing process that uses vulnerability scanning results as a baseline, lasting days or weeks depending on the scope.

Testing Ain’t Easy

Whether you use a tool or a service, complying with PCI Requirement 11.3 is a formidable task taking a combination of resources, time and a little bit of planning. In its simplest form, Requirement 11.3 mandates internal and external penetration testing at least annually or after “any significant infrastructure or application upgrade or modification”. Considering the volume of iterations of common operating systems and applications, I’d say we can throw out the idea of only testing annually. So, how do you test regularly and stay agile?

1. The right person or service: Take a look to see if any of your team members have pen testing experience. The great thing is that some penetration testing products, like Core Impact, have the option of using wizards to run various tests. This helps automate some of the more laborious tasks, while accomplishing the same goals in less time. As a supplement to this, try bringing on a more seasoned penetration tester or dedicated third-party security service.
2. The right tool: Depending on your needs and overall requirements scope, the tool you require may differ. Whatever it is, you need to be able to test regularly as things change in your environment. So, if you have one person on your team who only uses an open-source command-line based pen testing tool, with no other options, this could leave you in a bit of a pickle if he or she leaves. Be sure to have a backup plan.
3. The right methodology: Penetration testing doesn’t just happen and disappear. According to the new PCI Security Standards Council penetration testing guidelines, it requires a phased-approach involving pre-engagement, engagement, and post-engagement steps. These steps cover important topics such as timing, frequency, reporting, systems to target, success criteria etc. Preparing properly will help you stay on target, meet the PCI requirements, and not become overwhelmed. Well, not too overwhelmed at least.

Windows Privilege Escalation

• WPE-01 - Stored Credentials
• WPE-02 - Windows Kernel
• WPE-03 - DLL Injection
• WPE-04 - Weak Service Permissions
• WPE-05 - DLL Hijacking
• WPE-06 - Hot Potato
• WPE-07 - Group Policy Preferences
• WPE-08 - Unquoted Service Path
• WPE-09 - Always Install Elevated
• WPE-10 - Token Manipulation
• WPE-11 - Secondary Logon Handle
• WPE-12 - Insecure Registry Permissions

Security and Sandbox

It’s time to go beyond using sandboxing as a standalone capability in order to get the most out of it. You need a more robust malware analysis tool that fits seamlessly into your infrastructure and can continuously detect even the most advanced threats that are environmentally aware and can evade detection.

There are three typical ways that organizations purchase and deploy sandbox technology.

1. A stand-alone solution designed to feed itself samples for analysis without dependency on other security products. This has the most flexibility in deployment but adds significant hardware costs and complexity to management and analysis, especially for distributed enterprises.
2. A distributed feeding sensor approach, such as firewalls, IPS, or UTMs with built-in sandboxing capabilities. These solutions are usually cost effective and easy to deploy but are less effective in detecting a broad range of suspicious files including web files. They can also introduce bandwidth limitations that can hamper network performance and privacy concerns when a cloud-based solution is the only option.
3. Built into secure content gateways, such as web or email gateways. This approach is also cost effective but focuses on web and email channels only and also introduces performance limitations and privacy concerns.

Arcsight Threat Tracking Method

This Activate Method is used to track attackers and target system state and their progression through the attack life cycle. It consists of a set of rules that update the attacker and target threat scores as well as their progression and indicator and warning frequency within the attack life cycle. All this information is tracked in a set of lists with varying TTL for the entries.

For this to work efficiently, indicators and warnings have predetermined categorization requirements. For example, an IDS reporting shellcode over the wire is tagged with Category Custom Format Field = "/Attack Life Cycle/Delivery". The rules look for these conditions populate attacker and target information in the appropriate lists as well as the threat score tracking information.

Attack Life Cycle

The Attack Life Cycle lists are very straight forward. There is one list for each phase of the attack life cycle and the rules for getting attackers and targets into the lists follow two simple laws:

• Attackers and Targets can live in multiple list at the same time
• Only Activate rules will populate the lists

NOTE:

• Custom Category Format Field will be used to move data into the appropriate list
• All content is stored under:
  /All /ArcSight Activate/Use Cases/Threat Tracking/Attacke Life Cycle/ System Perspective/

Lists	Description
Phase 1 Reconnaissance	Will track attackers and targets that are conducting research and identification of targets. If the attacker's target can be derived from the event/analysis, then the target will also be tracked. Typically, these indicators and warnings and found by monitoring NIDS, HIPS, firewall ACLs, and web analytics.
Phase 2 Weaponization	Weaponization is not normally 'viewable' as the attacker normally creates weaponized packaged on systems that we are not in control of. This category will be used for file analysis tools that detect known IOC. (Mandiant, STIX, Tripwire)
Phase 3 Delivery	Indicators and warnings that intercept the transmission of executable code to a target. NIDS/HIPS/Proxies/in-line AV events are sources capable of detecting these events.
Phase 4 Exploitation	Execution of the attackers code. This list will track when code is executed either by the user or by exploiting a particular vulnerability. Indicators are warnings are detected at the OS/HIDS level. (SRP/ASLR/DEP)
Phase 5 Installation	Installation of remote access code. This can be detected at the OS/HIDS/AV
Phase 6 C2	Track attackers and hosts that are displaying beaconing characteristics. These are often detected by NIDS/FW acl/Honeypots/DNS, and detection can be enriched with external intel data
Phase 7 Objectives	Post "pawnage" activities (data exfil, corruption, destruction, pivots).

Arcsight Alert Suppression System

Suppression System

Analysts frequently need a method to suppress rules from firing until misconfigurations are resolved or point solutions are tuned. To support this activity a set of active lists will be maintained so the analysts can suppress correlation rules and data monitor alerts.

There are two sets of active lists. The first set is writable by all analysts and will have a TTL of 24 hours. These lists will be stored in "/All Active Lists/ArcSight Activate/Core/Suppression Lists". The second set of lists is only writable by L2 analysts and the TTL will be '0'. These lists will be stored in "/All Active Lists/ArcSight Activate/Core/Suppression Lists/Static".

NOTE: lists should have no more than 100 or so entries.

All logic used to compare new events to the suppression lists are stored in a filter under "/All Filters/ArcSight Activate/Core/Suppression List Filters". Should the need arise, simply create more lists and/or filters and document the hooks below.

To create more suppression lists, simply

1. Add an L1 list with 24hr TTL, "/All Active Lists/ArcSight Solutions/Administration/Suppression Lists"
2. Copy the list to the static directory and change the TTL to 0, "/All Active Lists/ArcSight Solutions/Administration/Suppression Lists/Static"
3. Change the appropriate filter, "All Filters/ArcSight Solutions/Administration/Suppression List Filters"
4. Update the documentation below

Hooking into the methodology

• Include the appropriate filter from "/All Filters/ArcSight Activate/Core/Suppression List Filters"
  • For network based events where all network based lists should take affect use: "All Network Based Suppression Lists"