Safety Norms: Ethical Hacking Methods

1Purpose, Scope, and Safety Principles

Ethical hacking methods identify security weaknesses in systems the tester has been explicitly authorized to assess. The work is safe only when it is planned, bounded, and recorded. Even well intended testing can disrupt production services, expose personal or confidential data, damage fragile equipment, or leave a path that a real attacker could reuse. These norms set the minimum conditions under which testing may proceed.

The norms cover reconnaissance, vulnerability identification, exploitation validation, credential auditing, web and API testing, cloud configuration review, authorized social engineering simulations, physical assessment support, reporting, and laboratory practice. They apply whether the work is paid, internal, academic, or volunteer.

• Mandatory: no test begins until written authorization from the legal owner of the target is on file.
• Mandatory: every engagement follows five principles: authorization first, least impact, minimum necessary data, reversibility where possible, and accurate reporting.
• Recommended: treat every target as if it supports a real business function, even when it is labeled a test environment.

2Roles, Competence, and Accountability

Each engagement names the people who hold specific responsibilities. The authorizing official, usually the system owner or an executive able to accept the risk, signs the rules of engagement and defines scope. The engagement lead plans the work, approves high impact steps, and holds the authority to stop activity. Testers perform the work, keep activity logs, and are personally accountable for the commands they run. A client contact, data custodian, and privacy or legal reviewer complete the chain. An incident lead coordinates response with the system operator when something goes wrong.

Competence is a precondition. Testers may only use methods they have practiced and can explain. Inexperienced people work under direct supervision in a lab before they touch any live target, and they must know when to stop and ask.

• Mandatory: rules of engagement must name the authorizing official, in scope assets, permitted methods, testing windows, emergency contacts, and stop conditions.
• Mandatory: no one tests a system they are not named to test, even if they have technical access to it.
• Mandatory: testers without recent documented experience in a method work under a qualified lead.
• Recommended: pair testers on high risk tasks such as exploitation against production adjacent systems or physical entry.

3Course Specific Hazards and Risk Assessment

Typical activities include host discovery, port and service scanning, vulnerability scanning, password auditing, web application fuzzing, proxy based interception, exploit validation, wireless capture, cloud permission review, phishing simulation, and on site physical testing. People affected include testers, system administrators, help desk staff, end users, executives who receive reports, and third party hosting or software providers. Tools include scanners, intercepting proxies, exploitation frameworks, password cracking utilities, and packet capture software. Environments range from isolated labs to production networks, shared cloud tenants, industrial control systems, building or medical systems, and physical facilities.

Assess risk by asset criticality, likelihood of unintended impact, and reversibility. Low risk is passive review of documented configuration. Moderate risk is authenticated scanning or single account checks in a defined window. High risk covers exploit validation, fuzzing, and any test that may crash a service or lock accounts. Critical risk covers anything touching safety related systems, regulated personal data, or live financial transactions, which requires added owner approval and usually professional oversight.

• Example: a credential spray against a directory that locks accounts after repeated failures can disrupt many staff, so it is high risk and needs an agreed threshold and window.
• Example: running an exploit against a legacy medical or industrial device without vendor guidance can cause patient or process harm, so it stays out of scope unless the owner and qualified professionals approve a safe method.
• Example: copying customer records to prove access is prohibited. Record the table name and a redacted count instead.
• Mandatory: document the risk level, owner acceptance, and residual risk before every high or critical activity.

4Preventive Controls and Safe Work Practices

Scope control is the most important preventive control. Keep a written list of in scope addresses, domains, applications, accounts, and cloud subscriptions, with explicit exclusions. Confirm each target against that list before acting. Scope changes require a written update signed by the authorizing official, since verbal changes are not enough. Shared infrastructure such as hosting providers may require separate permission.

Timing and throttling reduce impact. Schedule intrusive steps in agreed windows, cap scan rates, and avoid running several heavy tools at once. Prove impact with the least harmful method, such as reading a benign file the tester created, rather than destructive payloads. Denial of service testing is prohibited unless specifically authorized and monitored by the operator. Do not establish persistence or leave accounts behind unless the rules of engagement allow it, and remove all test artifacts before closing.

Credentials and data need their own rules. Prefer dedicated test accounts. Do not reuse captured credentials outside the scope where they were found. Access only the minimum data needed to demonstrate a finding, stop at proof, and redact screenshots. Social engineering must follow approved scenarios, avoid pretexts that invoke emergencies or threats, and include a debrief that supports affected staff. Physical testing requires a signed permit and carried authorization letters.

• Mandatory: stop immediately and notify the engagement lead if the target shows slowdowns, crashes, lockouts, or alerts suggesting a real incident.
• Mandatory: peer check any command that writes, deletes, restarts, or changes configuration before execution.
• Mandatory: never use testing access to read, copy, or alter data about individuals beyond what a finding requires.
• Recommended: prepare and verify a rollback or restore point before any change to a live system.
• Recommended: run scanners from a known address so the operator can distinguish tests from attacks.

5Equipment, Environment, Information, and Protective Safeguards

Testing workstations should be dedicated, hardened, patched, and separated from personal activity. Use multifactor authentication for engagement accounts and reach client networks only through an approved VPN or bastion host. Verify tool integrity from trusted sources and record versions in the engagement log. Keep an approved tool inventory so unreviewed utilities never enter client environments. Malware samples, exploit code, and captured traffic belong in a controlled repository with access logs, not on general purpose laptops.

Engagement information is sensitive. Encrypt evidence at rest and in transit, limit access to named team members, and set a retention period in the rules of engagement. At closure, return or securely destroy evidence and confirm destruction in writing. Privacy rules vary by jurisdiction and sector, so treat personal data as regulated, minimize collection, and consult the privacy reviewer first. Labs should be isolated from production and the public internet.

For on site work, wear site required protective equipment such as high visibility clothing, visitor badges, and any protective footwear the site mandates. Follow electrical and cabling rules, avoid server rooms without an escort, limit long sessions to reduce fatigue errors, and keep cables out of walkways. For remote work, apply equivalent safeguards such as a locked screen and a dedicated workspace.

• Mandatory: no client data on personal devices or unmanaged storage.
• Mandatory: run test tooling only from approved, patched, and inventoried systems.
• Recommended: use a separate account or device for preparing sensitive reports.

6Incident Reporting, Emergency Response, and Escalation

Define stop work triggers in advance. Stop and report immediately if testing causes an outage or unexpected data change, reveals evidence of an active attacker, exposes data outside scope, affects a third party, or creates an injury or physical hazard. Report near misses, such as a scan that nearly triggered a lockout, so controls can improve. Do not repair production systems unless the owner directs the work.

The response sequence is consistent. First, stop all active test traffic and secure the workstation. Second, preserve logs, timestamps, and command history without altering them. Third, notify the engagement lead and client emergency contact within the timeframe in the rules of engagement. Fourth, record facts only. If a person is injured or in danger, contact emergency services first, then the site lead. Suspected criminal activity is escalated through the client, legal counsel, or law enforcement as local law directs.

Vulnerability disclosure follows the agreed process. Report critical findings promptly through approved channels, and do not publish or share them without written approval. Disclosure timelines and legal duties vary by jurisdiction, so confirm them with counsel before any external communication.

• Mandatory: report any out of scope access within the window set in the rules of engagement, even if no data was viewed.
• Mandatory: never delete or edit logs or artifacts to hide an exception.
• Recommended: hold a short post incident review to identify control gaps.

7Records, Training, Inspection, and Review

Records prove that testing was authorized, bounded, and safe. Keep the authorization letter, rules of engagement, scope list, testing windows, timestamped activity log, tool versions, findings, incident reports, and data disposition record. Review logs against scope before the report is issued and explain any discrepancy in writing. Verify retention requirements locally.

Training is continuous. New testers complete instruction on these norms, lab exercises for each method, and supervised live work. Experienced testers refresh skills periodically and after major tool or platform changes. Clearance for each method should be documented and can be withdrawn after an incident or lapse.

Review closes the loop. After each engagement, hold a lessons learned session covering scope accuracy, tool behavior, stop decisions, and report quality. Update these norms and local procedures when issues recur. Peer review and random log audits detect scope drift early. Measure performance with observable indicators such as scope exceptions, near misses reported, and time to close findings. These norms are a starting point, not a complete procedure, and they should be adapted to local approved procedures with qualified professional input for regulated areas.

• Mandatory: keep authorization and scope records with the engagement file until closure and retention obligations are met.
• Mandatory: withdraw method clearance from anyone who exceeds scope or bypasses a stop decision until retraining is complete.
• Recommended: review these norms whenever tooling, client environments, or applicable rules change significantly.

Implementation checklist

• Confirm written authorization and signed rules of engagement before any testing begins.
• Check every target against the in scope list before each action.
• Classify each planned activity as low, moderate, high, or critical risk and record owner acceptance.
• Schedule intrusive activity within agreed windows and cap scan rates.
• Peer check commands that write, delete, restart, or change configuration.
• Use dedicated test accounts, minimize data access, and redact evidence.
• Stop and report immediately on outages, lockouts, unexpected alerts, or out of scope access.
• Store engagement data encrypted, limit access, and document secure destruction at closure.
• Verify local laws, standards, and contract terms with qualified advisers before acting.
• Complete a lessons learned review and update these norms after each engagement.