Good Practices and Ethics of Your Personal Lab

You have built a lab that can run attack tools. That is a power, and with it comes a responsibility that every professional in this field takes seriously. This lesson is the one to reread before each new practical session. It covers the legal framework in plain language, the habits that keep a lab safe, and the code of conduct that distinguishes an ethical hacker from a criminal.

Chapters 1 and 2 taught you how networks work. Chapter 3 gave you the tools to explore them. This lesson sets the boundaries, because skills without ethics are not a profession.

The golden rule: authorisation

The whole difference between a security professional and an attacker is one word: authorisation. The same scan, the same tool, the same technique is a legitimate job when the owner of the system has agreed in writing, and an offence when they have not. Curiosity, good intentions or "I only wanted to show them the flaw" are not defences.

In your lab, the authorisation question is simple, because you own everything. It becomes serious the moment something leaves the lab. That is why the rest of the lesson keeps coming back to isolation and discipline.

The legal framework in France

In France, the Code pénal punishes offences against automated data processing systems in articles 323-1 to 323-3-1. In plain language:

• Article 323-1: fraudulently accessing or remaining in all or part of an automated data processing system is an offence, even if nothing is stolen or damaged. The penalties are increased if the access results in deletion or modification of data, or alters the operation of the system.
• Article 323-2: hindering or distorting the operation of such a system, for example through denial of service.
• Article 323-3: fraudulently introducing, extracting, modifying or deleting data in such a system.
• Article 323-3-1: importing, holding, offering or making available, without legitimate reason, equipment, an instrument, a program or data designed or adapted to commit these offences. The words "without legitimate reason" matter: security research, teaching and professional testing are legitimate reasons, which is why owning Kali is not a crime. They also explain why you should keep your activity documented and clearly tied to training.

The exact penalties and the current wording are available on the official legal portal, legifrance.gouv.fr, which you should consult rather than trust a summary, including this one. The detailed legal framework of penetration testing is the first lesson of chapter 7.

Other countries have comparable laws: for example, the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act in the United Kingdom, and, at the European level, a directive on attacks against information systems that countries transposed in their national law. The Budapest Convention on cybercrime is an international treaty that many states have signed. The details differ, but the principle is the same everywhere: no access without authorisation.

The code of conduct of the ethical hacker

Beyond the law, the profession has principles that you should adopt from the start:

1. Authorisation and scope: act only on systems you own or are explicitly authorised to test, and stay inside the defined scope.
2. Minimal harm: avoid disrupting services or exposing data. When a test could cause damage, stop and ask.
3. Confidentiality: if you see sensitive information during an authorised test, you protect it and do not share it.
4. Honesty: report what you find accurately, including your own mistakes.
5. Responsible disclosure: if you discover a vulnerability in a system by accident or in a bug bounty programme, report it through the proper channel and give the owner reasonable time to fix it before any publication. This is known as coordinated disclosure.
6. Continuous learning: tools and threats change, and so does the law.

Official resources help you stay on the right side. In France, the ANSSI publishes guidance at cyber.gouv.fr, and the government's assistance platform cybermalveillance.gouv.fr helps victims of cyberattacks. Internationally, OWASP offers testing guides and ethical principles for web security, and the MITRE ATT&CK knowledge base documents adversary behaviour for defenders.

Hygiene of the lab

A safe lab results from habits more than from technology. Adopt this checklist:

• Keep the network isolated. Before every session, check that the adapters are internal or host-only, and that the NAT adapter is disconnected when not needed.
• Double-check every target address before running any tool. In a /24 lab, every address starts with 10.10.10.; if it does not, stop.
• Separate roles. Do your offensive work in the Kali VM, not on your host and not on the computer that holds your personal accounts and files.
• Do not reuse real credentials inside the lab. Use throwaway accounts and passwords: a lab machine may log or expose them.
• Keep the host and the hypervisor up to date. A vulnerability in the hypervisor could in theory allow an escape from a guest, and updates are your protection.
• Limit host-guest integration. Disable shared folders, shared clipboard and drag and drop on machines running vulnerable or suspicious software.
• Use legal targets only. Machines you built yourself, intentionally vulnerable applications such as DVWA and OWASP Juice Shop, and the platforms made for learning: PortSwigger Web Security Academy, TryHackMe and HackTheBox. Follow each platform's rules, which forbid, for example, attacking the platform's own infrastructure.
• Download carefully. Get tools and images from official sources, verify checksums, and never run a "tool" found on a random forum without understanding it.
• Back up your notes and your key VMs outside the VM.
• Keep a log. A dated lab notebook is useful for learning, and it also documents the fact that your activity was legitimate training.

Privacy and data of others

Even legitimate captures and tests can involve other people's data. In a lab, create fake data rather than copying real databases. If you ever practise on a real authorised environment, remember that personal data is protected by the GDPR in Europe: collect only what is necessary, secure it, and delete it when the mission ends.

Your turn: write your lab charter

In your lab notebook, write a one-page "lab charter" in your own words. It should contain: the list of systems you are allowed to test (your own VMs and the named legal platforms), five rules you commit to follow (use the checklist above), what you do if you accidentally access something that is not yours, and the sentence that summarises the legal principle in your country. Then do a pre-flight check of your lab: verify the adapter modes of each VM, and the isolation test from lesson 3.