Cybersecurity and Ethical Hacking: Foundations

A cybersecurity task often begins with an ordinary workplace question: which information matters, who can reach it, and what are you authorised to do? Those answers shape safe decisions whether you work in a university, a small charity, a public service or a large employer. A clear map also helps you explain risk without turning every discussion into a list of technical threats.

You will start by identifying assets, users and the boundaries where trust changes. Then you will use confidentiality, integrity and availability to describe what could go wrong for real workplace services. Finally, you will distinguish written permission to test a system from a public invitation to use it. These ideas give you a practical basis for discussing security work with colleagues and for avoiding activity that exceeds your authority. The chapter ends with a scenario that brings the three skills together.

An asset is something an organisation values and needs to protect. It can be information, a device, a service, a facility, or the people and processes that keep work going. Do not limit the word to computers. A customer record, a payroll process, a staff laptop and the skill needed to restore a service can all be security-relevant assets.

Users are people or other entities that interact with those assets. They include staff, customers, contractors, suppliers and software services acting on someone's behalf. A user is not automatically trustworthy or untrustworthy. The useful question is what access they need, for what purpose, and under whose authority.

A trust boundary is a point where control, ownership or expected behaviour changes. A staff member signing in from a personal device crosses a boundary between an organisation-managed environment and a device the organisation may not control. A website receiving information from a visitor crosses a boundary between public input and internal systems. Boundaries can be physical, technical, organisational or contractual.

Use a simple structure for your map: list the asset, its owner or responsible team, the people and services that can reach it, and the boundary each access path crosses. Add how access is granted, such as a staff account, a customer login or a service connection. The purpose is not to draw every technical detail. It is to make important relationships visible enough for a useful conversation.

Suppose Anika, an information security analyst at a university in Lahore, is helping review an online student-support service. She lists student contact details, the service itself and the staff process for responding to requests as assets. Students submit requests through a public page. Support staff use named accounts to view them. A separate technical service stores the records. Her map marks the public page as an external entry point, staff sign-in as a boundary between general visitors and authorised staff, and the connection to storage as a boundary between the web service and stored information.

This map prompts concrete questions. Does every staff member need access to every request? Can the public page accept unexpected data? Which team can change the service? Who notices if access stops working? Anika does not assume the answers. She records uncertainties and asks the responsible teams.

A common mistake is to map only servers and software. That misses the information and human work that give those systems value. Another is to label a whole network as trusted. Trust is usually specific to an action or relationship. A person might be allowed to read a record but not change it. A service might be allowed to send a request but not approve its own access.

Confidentiality means information is not disclosed to people who lack authority to see it. Integrity means information and systems remain accurate and are changed only in authorised ways. Availability means authorised people can use information and services when their work requires them. These are connected needs, but they are not interchangeable.

A service can preserve confidentiality while failing availability. For example, a locked system may keep records hidden from outsiders but also prevent authorised staff from doing their jobs. A service can be available while its integrity has failed, if staff can log in but see altered records. A file can remain accurate while confidentiality fails because an unauthorised person has copied it.

The terms help you describe outcomes before choosing a technical control. They also help teams discuss trade-offs. A short service interruption might be acceptable for a planned repair, while an inaccurate payment instruction could create a different kind of harm. The right response depends on the work and on the consequences of failure.

Suppose Marta, an operations analyst at a regional bank in Warsaw, helps a team review an internal payment instruction service. For confidentiality, she asks whether only staff with a work-related need can view instructions and related customer details. For integrity, she asks how the team distinguishes an authorised correction from an unauthorised alteration. For availability, she asks which payment tasks stop if staff cannot reach the service, and what approved fallback exists.

Her questions lead to different kinds of safeguards. Access controls can limit who sees records. A controlled approval or change process can help protect integrity. Backups, recovery arrangements and service monitoring can support availability. No single measure solves every problem. A backup might help restore information after an outage, but it does not stop someone with excessive access from reading it. A login requirement might restrict access, but it does not establish that saved information is correct.

When discussing a proposed change, describe the information or service, the affected people, and the security need at stake. Avoid saying only that a system is 'secure' or 'unsafe'. Ask what could be seen, changed or made unavailable. Record assumptions, such as whether a backup can actually be restored or whether a proposed user group needs access to all records.

A common misconception is that security means keeping information secret. That puts confidentiality ahead of everything else and can leave accuracy or continuity unexamined. Another is to treat availability as a promise that a service can never be interrupted. In practice, teams make decisions about acceptable interruption and recovery. Those decisions should reflect the consequences for the people who depend on the service.

Ethical security testing is work carried out with permission from someone who has authority over the systems being tested. Permission should be explicit and written. It should identify the systems or services in scope, the testing dates or conditions, the people responsible for approval, the methods allowed, and what to do if a test causes an unexpected effect. The precise form depends on the organisation and engagement, but a vague conversation is a poor basis for potentially disruptive work.

A public invitation to use a website, app or online account gives you permission to use its advertised functions under the terms presented to ordinary users. It does not, by itself, give you permission to probe the service, attempt to bypass controls, access other users' information or disrupt normal operation. A security contact address is not necessarily an invitation to test. A published testing programme may set specific rules, but you must read its scope and restrictions before acting.

Authority also has limits. Permission to assess one web service does not automatically cover its supplier, connected systems, staff accounts or the organisation's wider network. A good tester checks the boundary rather than assuming that technical connection means approval.

Suppose Chidi, a security analyst at a logistics firm in Lagos, is asked by a colleague to check whether a customer portal exposes account details. The colleague has noticed an unusual page and says, "Can you see what else it shows?" Chidi does not begin exploring. The request may be a genuine concern, but it does not establish that the colleague has authority to approve testing or define its limits.

Chidi asks who owns the portal, who can authorise security testing, which exact service is included, and what actions are permitted. He also asks how to report a finding and whom to contact if the service behaves unexpectedly. Suppose the written approval covers only a test environment and forbids changes to stored information. Chidi must stay within that scope. If he discovers a route to a live service, he stops and seeks clarification rather than treating discovery as permission.

Ethical conduct includes minimising harm, protecting information you encounter, keeping appropriate records and reporting findings through the agreed channel. Do not copy, retain or share personal or business data merely to prove that it was reachable. If you encounter information outside the agreed scope, stop interacting with it and follow the reporting instructions. If a test causes an unexpected service change, pause the activity and contact the named owner.

Legal rules differ across places, but most countries treat unauthorised access to a computer system as an offence even when nothing is damaged. Examples include the Computer Misuse Act 1990 in the United Kingdom, the Computer Fraud and Abuse Act in the United States and sections 43 and 66 of the Information Technology Act 2000 in India. If a proposed test raises a legal or contractual question, treat that as a reason to obtain guidance from the organisation's authorised legal or security contacts before acting. This chapter does not replace that advice.

A common mistake is to believe good intentions make unapproved activity acceptable. They do not. Another is to treat a colleague's request, a bug report form or ordinary access to a public service as blanket authority. Permission must be specific enough for you to know what you may test and where your authority ends.

A strong response names the asset, the users and access routes, and the boundary between public use and authorised testing. It explains whether a concern affects confidentiality, integrity or availability. It does not treat curiosity, access or good intentions as permission. You can now map basic security relationships and distinguish permitted testing from unauthorised activity.