312-50 Question 17
Single answer▪ Information Security Laws and StandardsA CEH-certified consultant is hired to perform an external penetration test against a healthcare provider that stores patient records and processes credit card payments. During scoping, the client asks the consultant to reuse a broad authorization letter from a previous engagement and begin testing immediately, including a third-party cloud-hosted patient portal. The consultant knows the provider must comply with multiple legal and regulatory requirements. What is the MOST appropriate next step before starting the assessment?
- A
Begin testing because the client is the data owner, and the previous authorization letter is sufficient for all related systems
- B
Obtain a current, written rules-of-engagement document that explicitly defines scope, authorization, handling of protected health information, and permission for any third-party hosted assets before testing
- C
Start with only vulnerability scanning of the cloud-hosted portal because passive or low-impact testing does not require formal authorization
- D
Exclude the patient portal from the assessment but proceed against all other systems because HIPAA permits security testing only on internally hosted medical systems
Show answer and explanation
Correct answer: B
Explanation
The best answer is to obtain a current written rules-of-engagement document with explicit authorization before any testing begins. In real engagements, ethical hackers must verify legal authority, scope, and constraints, especially when multiple compliance frameworks and third parties are involved. For a healthcare provider, HIPAA's Security Rule requires safeguards for electronic protected health information, which affects how testing is planned and how data is handled. Because the organization also processes payment cards, PCI DSS may impose requirements related to vulnerability management and penetration testing, but PCI DSS does not replace the need for explicit authorization. If systems are hosted by a cloud or SaaS provider, the tester must also confirm that the customer's contract and the provider's testing policy permit the planned activity. This reflects standard penetration testing practice: get written authorization, define scope and limitations, identify sensitive data handling requirements, and ensure third-party permissions are in place. Relevant references include the HIPAA Security Rule, PCI DSS requirements for security testing, and commonly accepted penetration testing best practices such as formal rules of engagement and documented authorization.
- A. Incorrect.
This is incorrect because a prior or overly broad authorization letter may not cover the current engagement, systems, dates, methods, or third-party environments. In penetration testing, explicit and current written authorization is essential to avoid unauthorized access claims. Ownership of data does not automatically grant authority to authorize testing of third-party hosted assets under a separate provider's control.
- B. Correct.
This is correct because the consultant should ensure there is a current, explicit, written authorization and rules of engagement covering scope, timing, permitted techniques, data handling requirements, and third-party approvals. In this scenario, the healthcare provider implicates HIPAA-related protections for electronic protected health information, and payment processing may invoke PCI DSS contractual requirements. Testing a cloud-hosted portal also requires confirmation that the client has authority and that the cloud provider permits such activity under its policies and contracts.
- C. Incorrect.
This is incorrect because even low-impact scanning can still be unauthorized if performed without proper approval. A common misconception is that only exploitative testing requires formal authorization. In practice, scanning third-party hosted assets without documented permission can violate acceptable use terms, service agreements, or legal boundaries.
- D. Incorrect.
This is incorrect because HIPAA does not prohibit security testing of systems simply because they host medical data, nor does it limit testing to internally hosted systems. The issue is not whether testing is allowed, but whether it is properly authorized, scoped, and conducted with safeguards for protected data. Excluding the portal without clarifying authorization also fails to address the broader documentation and compliance issues.