Foundations of Network and Information SecurityIntroduction and ContextNetwork and information security is the discipline concerned with protecting information, information systems, networks, devices, services, and people from unauthorized activity, accidental damage, misuse, disruption, and deception. It is both a technical and organisational field. Firewalls, encryption, identity systems, and monitoring are important, but security also depends on governance, procedures, human behaviour, supplier relationships, legal obligations, and informed risk decisions. Modern organisations depend on interconnected systems. A university may store student records in cloud platforms, use wireless networks for teaching, rely on email and identity providers, and exchange data with government agencies and payment services. Each connection creates value, but also creates opportunities for compromise. Security therefore cannot be treated as a single product or as the responsibility of one department. It is a continuous process of identifying what must be protected, understanding possible harm, reducing risk, detecting events, responding effectively, and recovering safely. This chapter introduces the vocabulary and principles required for later study of network defence, secure architecture, incident response, governance, and digital forensics. Learning ObjectivesAfter completing this chapter, you should be able to: - Define assets, threats, vulnerabilities, exploits, risks, controls, and attack surfaces.
- Distinguish confidentiality, integrity, availability, authenticity, accountability, and non-repudiation.
- Apply least privilege, defence-in-depth, secure-by-design, and risk-based security principles.
- Analyse a simple system to identify assets, attack paths, vulnerabilities, and appropriate controls.
- Explain how technical, administrative, physical, and human controls complement one another.
- Recognise ethical, legal, governance, and operational responsibilities in security work.
The Security VocabularySecurity discussions become confused when closely related terms are used interchangeably. The following distinctions are fundamental. AssetsAn asset is anything that has value to an organisation or individual and therefore requires protection. Assets include data, hardware, software, services, credentials, facilities, processes, reputation, intellectual property, and human safety. An asset may be valuable because of its financial value, operational importance, legal significance, privacy implications, or role in public safety. A database is not the only asset in a database system. The records, database server, backup copies, administrator accounts, encryption keys, network connections, and business processes may all be separate assets. Asset identification should also consider dependencies. If an online examination system depends on an identity provider and a cloud storage service, those external services form part of its operational asset environment. Threats and Threat ActorsA threat is a circumstance or event that could adversely affect an asset. A threat actor is the person, group, organisation, or automated process capable of carrying out a harmful action. Threat actors include cybercriminals, insiders, hacktivists, espionage groups, competitors, careless users, and occasionally natural or technical forces such as floods, power failures, and software defects. Threats may be intentional or accidental. Examples include credential theft, ransomware, an employee sending confidential information to the wrong recipient, a failed disk, and a denial-of-service attack. A threat does not necessarily mean that harm will occur; it describes a potential source of harm. VulnerabilitiesA vulnerability is a weakness that can be exploited or can otherwise contribute to an undesirable outcome. Examples include an unpatched web server, excessive user permissions, weak passwords, insecure default configurations, inadequate physical access controls, and an absence of tested backups. Vulnerabilities may be technical, procedural, physical, organisational, or human. A technically secure application may still be vulnerable if its administrator accounts are shared or if recovery procedures have never been tested. Exploits and AttacksAn exploit is a method, technique, or code that takes advantage of a vulnerability. An attack is an attempt, whether successful or unsuccessful, to compromise an asset or security property. For example, a vulnerable web application is the weakness; a crafted input designed to trigger the weakness is an exploit; and the attacker’s overall activity is an attack. The distinction matters operationally. Vulnerability management identifies weaknesses, threat intelligence describes likely threat actors and methods, and detection systems seek evidence of attacks or exploitation. RiskRisk is the possibility of adverse consequences arising from uncertainty. In practical security work, risk is often discussed using likelihood and impact. A simple qualitative model is: Risk ≈ Likelihood × Impact Likelihood describes how probable or plausible an event is within a defined period, while impact describes the magnitude of harm if it occurs. This expression is a decision aid, not a universal physical law. Organisations may use numerical, ordinal, scenario-based, or qualitative methods. Risk assessments must state their assumptions, scope, time horizon, and impact criteria. A high-impact event with low likelihood may deserve attention because of safety, legal, or strategic consequences. Conversely, a frequent event with minor impact may justify automated controls. Risk is not eliminated by declaring a system “secure”; it is reduced, transferred, avoided, accepted, or shared through informed decisions. Controls and SafeguardsA control is a measure that modifies risk. Controls may prevent, deter, detect, respond to, correct, or recover from adverse events. They may also be classified by their nature: | Control category | Examples |
|---|
| Administrative | Policies, risk assessments, training, contracts, segregation of duties | | Technical | Access control, encryption, firewalls, secure configuration, logging | | Physical | Locks, guards, environmental controls, secure disposal | | Preventive | Multi-factor authentication, patching, network segmentation | | Detective | Intrusion detection, audit logs, integrity monitoring | | Corrective and recovery | Malware removal, restoration, incident lessons, failover |
A control is not automatically effective because it exists. Its design, implementation, coverage, maintenance, usability, and monitoring determine its practical value. Security Properties and ObjectivesConfidentialityConfidentiality means preventing unauthorized disclosure of information. Encryption, access control, data classification, secure disposal, and network segmentation support confidentiality. Confidentiality is not the same as secrecy in every circumstance: authorised users and systems may need access, but access must be limited to legitimate purposes. IntegrityIntegrity is the protection of information and systems against unauthorized or improper modification, destruction, or corruption. Hashes, message authentication codes, digital signatures, transaction controls, versioning, backups, and change management can support integrity. Integrity also includes correctness and completeness where those properties are required by the process. AvailabilityAvailability means that authorised users can access information and services when required. Resilience, redundancy, capacity management, backups, maintenance, disaster recovery, and denial-of-service protection support availability. Availability is not identical to continuous operation; a service may meet its agreed availability objective while undergoing scheduled maintenance. The confidentiality, integrity, and availability triad is commonly called the CIA triad. The properties can conflict. Strong encryption may increase processing overhead; extensive availability may require replicated data and therefore increase the number of systems that must be protected. Security engineering therefore involves balancing requirements rather than maximising one property in isolation. Authenticity and AuthenticationAuthenticity concerns whether an entity, message, system, or data source is genuine. Authentication is the process of verifying an identity or claimed origin. Passwords, hardware tokens, certificates, biometrics, and cryptographic signatures can support authentication. Authentication does not by itself determine what an authenticated user may do; that is an authorisation decision. AccountabilityAccountability means that actions can be attributed to responsible entities and examined through reliable evidence. Individual accounts, tamper-resistant logs, time synchronisation, monitoring, and documented procedures support accountability. Shared administrator accounts weaken it because investigators cannot confidently associate an action with one person. Non-repudiationNon-repudiation is evidence supporting the claim that a party performed an action or originated data, such that denial is difficult within the relevant legal and technical context. Digital signatures, trusted timestamps, certificate infrastructure, and controlled key management may contribute to non-repudiation. A log entry alone is not automatically non-repudiation: its reliability depends on identity assurance, protection from alteration, system design, and applicable law. Core Security PrinciplesLeast PrivilegeLeast privilege requires each subject, process, device, and service to receive only the permissions necessary for its authorised tasks, for only as long as necessary. It reduces the consequences of compromised accounts and limits accidental misuse. Implementation techniques include role-based access control, just-in-time administration, separate privileged accounts, regular access reviews, service-account restrictions, and removal of dormant privileges. Least privilege can be difficult when responsibilities change rapidly, when applications require broad permissions, or when emergency access is needed. Those difficulties justify better processes and monitored exception mechanisms, not abandonment of the principle. Defence in DepthDefence in depth uses multiple, independent or partially independent layers of protection. A typical arrangement may include secure development, identity controls, endpoint protection, network segmentation, firewalls, application validation, encryption, logging, backups, and trained personnel. If one layer fails, another may prevent, detect, contain, or recover from the incident. Layering does not mean purchasing many overlapping products. Controls should address different failure modes and should be tested together. Poorly configured layers can create complexity without meaningful protection. Secure by Design and Secure by DefaultSecure-by-design means that security requirements are considered during architecture, development, procurement, and change planning rather than added after deployment. Threat modelling, abuse-case analysis, secure coding, privacy considerations, dependency management, and security testing are design activities. Secure-by-default means that the initial configuration provides the safer practical setting: unnecessary services are disabled, access is denied unless authorised, logging is enabled appropriately, and default credentials are removed. Users may receive additional access through an explicit, justified process. Zero Trust as a Modern Application of Fundamental PrinciplesZero trust is an architectural approach that avoids granting implicit trust merely because a user or device is inside a network boundary. It emphasises explicit authentication and authorisation, least privilege, continuous evaluation, device and session context, segmentation, and comprehensive monitoring. Zero trust does not mean that trust is impossible; it means that trust decisions are specific, evidence-based, and continually revisable. Attack Surfaces and Attack PathsAn attack surface is the collection of points through which an attacker might interact with, influence, access, or disrupt a system. It includes internet-facing services, wireless access points, remote-access tools, APIs, endpoints, mobile devices, cloud interfaces, software dependencies, administrative interfaces, supply-chain connections, removable media, and human processes. Attack surface management involves discovering assets, identifying exposure, classifying importance, removing unnecessary services, hardening configurations, patching weaknesses, and monitoring changes. It is continuous because systems, suppliers, software versions, and business requirements change. An attack path is a sequence of actions or conditions that could lead from an entry point to a target. For example: - An attacker obtains a password through phishing.
- Multi-factor authentication is absent or bypassed.
- The account has excessive permissions.
- A file server contains sensitive records.
- Logs are incomplete, delaying detection.
This sequence shows why security cannot focus only on the initial vulnerability. Identity controls, privilege management, segmentation, data protection, and monitoring each influence the path. A useful analysis method is to map trust boundaries. A trust boundary is a point where data, authority, or assumptions change—for example, between the public internet and an application, between a user workstation and a server, or between an organisation and a cloud provider. Controls should be explicit at each boundary. A Practical Risk-Analysis MethodA security analyst can use the following disciplined process: - Define scope. Identify the system, business process, locations, dependencies, and assessment period.
- Inventory assets. Record data, services, devices, identities, keys, suppliers, and facilities.
- Identify security requirements. Determine confidentiality, integrity, availability, authenticity, and legal or business obligations.
- Identify threats and threat actors. Consider intentional, accidental, environmental, and supply-chain events.
- Identify vulnerabilities and exposure. Examine configurations, architecture, processes, people, and dependencies.
- Construct plausible scenarios. Describe an asset, threat, weakness, event, consequence, and existing controls.
- Evaluate risk. Estimate likelihood and impact using a defined scale or model.
- Select treatments. Avoid, reduce, transfer, share, or accept risk with documented authority.
- Verify controls. Test effectiveness, not merely implementation.
- Monitor and review. Update the assessment after changes, incidents, new intelligence, or altered business priorities.
Risk registers should record ownership, treatment decisions, due dates, residual risk, and acceptance authority. Risk acceptance is a management decision and should not be silently imposed on technical staff. Worked Application: University Research PortalThe following is an illustrative case. BackgroundA university operates a research portal through which staff upload research proposals and confidential partner documents. Users authenticate remotely. The portal is hosted in a public cloud and connects to an internal identity service and a document repository. ProblemA review identifies several concerns: the portal permits password-only login, an obsolete component is exposed to the internet, administrators use the same account for routine and privileged work, and backups have not been restored in a test. Audit logs record successful logins but not document downloads. AnalysisImportant assets include research documents, identity records, administrator credentials, the portal service, the document repository, and the university’s research reputation. Threats include credential phishing, exploitation of the obsolete component, malicious insiders, accidental deletion, and ransomware affecting connected storage. Vulnerabilities include weak authentication, exposed outdated software, excessive privilege, incomplete audit evidence, and unverified recovery. The attack surface includes the public portal, login interface, cloud management plane, administrator endpoints, identity connection, and repository integration. The principal security requirements are confidentiality of partner documents, integrity of proposals, availability during funding deadlines, authenticity of submissions, and accountability for downloads and administrative changes. Approach and SolutionThe university should first remove or isolate the obsolete component and apply a supported update. Multi-factor authentication should be required for administrators and, where feasible, all users. Separate privileged accounts should be introduced, with just-in-time elevation for exceptional administration. Access should be role-based and limited by project membership. The portal should be placed behind suitable application and network controls, with the repository separated from public-facing components. Download, privilege-change, authentication, and configuration events should be logged centrally, protected from unauthorised alteration, and reviewed through alerts. Sensitive documents should be encrypted in transit and at rest, with carefully governed key access. Backups should follow defined recovery objectives and be tested through controlled restoration. The university should conduct a phishing-awareness programme, establish an incident-response process, review cloud-provider responsibilities, and perform a follow-up assessment. OutcomeThese measures reduce the likelihood of unauthorised access, limit the damage from a compromised account, improve detection, and provide evidence for investigation. They do not eliminate risk. The university must continue patching, reviewing access, testing recovery, and reassessing supplier and application changes. Learning PointsThe case demonstrates that a single security objective depends on multiple controls. Confidentiality requires identity assurance, authorisation, segmentation, encryption, monitoring, and sound administration. Availability requires not only redundant technology but also tested recovery. Accountability requires useful logs and individual attribution. The best control set is therefore a coordinated system rather than a collection of isolated products. Governance, Ethics, and Professional ResponsibilitySecurity professionals operate with significant authority. They may inspect traffic, access systems, test vulnerabilities, or handle sensitive personal information. Such activity must be authorised, proportionate, documented, and consistent with law and organisational policy. Penetration testing without permission can be unlawful even when the intention is beneficial. Privacy principles require purpose limitation, data minimisation, appropriate retention, access control, and protection against unauthorised disclosure. Monitoring should have a legitimate purpose and should avoid collecting more information than necessary. Organisations must also consider accessibility, discrimination, and the effect of security controls on legitimate users. Governance establishes who is accountable for decisions. Common responsibilities include asset ownership, risk ownership, system administration, data protection, incident response, audit, and executive oversight. Frameworks and standards such as the NIST Cybersecurity Framework, ISO/IEC 27001, and CIS Controls can provide structure, but no framework replaces contextual judgement or evidence of effective implementation. Supply-chain governance is increasingly important. Organisations should evaluate software provenance, supplier access, vulnerability disclosure, update processes, data location, subcontractors, service continuity, and exit arrangements. Cloud security is a shared responsibility: the provider and customer each control different layers, and the division must be understood rather than assumed. Contemporary Developments and LimitationsArtificial intelligence can assist defenders by correlating alerts, summarising logs, identifying unusual behaviour, and supporting secure-code review. It can also introduce risks, including inaccurate recommendations, data leakage, prompt manipulation, automated phishing, and difficult-to-explain decisions. AI outputs require human validation, controlled data handling, and appropriate accountability. Automation improves consistency but can amplify mistakes. An automated access change, patch deployment, or blocking rule may affect thousands of systems. Changes should therefore use approval thresholds, testing, rollback plans, monitoring, and emergency procedures. Security metrics must be interpreted carefully. Counting vulnerabilities, alerts, or training completions does not directly measure risk reduction. More meaningful measures may include the time to remediate critical exposure, the proportion of privileged accounts using strong authentication, the success rate of tested recovery, detection time, containment time, and the percentage of assets with known owners. Metrics should support decisions rather than encourage superficial compliance. No control is perfect. Encryption does not prevent an authorised user from misusing decrypted information. Multi-factor authentication reduces credential abuse but may be bypassed through social engineering or session theft. Backups may be encrypted by ransomware if they remain continuously connected. Defence-in-depth, testing, monitoring, and adaptation are therefore essential. Best-Practice PrinciplesA mature foundational programme should: - maintain an accurate asset inventory and ownership model;
- classify information according to sensitivity and business impact;
- use strong authentication and least privilege;
- remove unnecessary exposure and secure default configurations;
- patch according to risk and verify remediation;
- segment networks and protect trust boundaries;
- encrypt sensitive information appropriately and manage keys securely;
- collect, protect, and review meaningful logs;
- maintain tested, isolated, and recoverable backups;
- train personnel using realistic scenarios;
- prepare and exercise incident-response and continuity plans;
- assess suppliers and cloud responsibilities;
- review controls after changes and incidents; and
- document risk decisions, exceptions, ownership, and residual risk.
Chapter SummaryNetwork and information security protects valuable information and services from unauthorised disclosure, alteration, destruction, disruption, and deception. Assets include data, systems, credentials, processes, people, facilities, and reputation. Threats describe potential sources of harm; vulnerabilities are weaknesses; exploits are methods of taking advantage of weaknesses; attacks are attempts to compromise assets; and controls modify risk. The CIA triad provides the central objectives of confidentiality, integrity, and availability. Authenticity verifies genuineness, accountability links actions to responsible entities, and non-repudiation provides stronger evidence concerning origin or action. Least privilege limits authority, defence in depth provides multiple protective layers, and secure-by-design incorporates security throughout the system lifecycle. Zero trust applies these ideas by requiring explicit, context-aware, and continually evaluated access decisions. Attack surfaces include technical, human, physical, cloud, and supply-chain entry points. Effective analysis maps assets, threats, vulnerabilities, trust boundaries, attack paths, consequences, and controls. Security is also a governance and ethical responsibility: actions must be authorised, privacy must be respected, and risk decisions must have accountable owners. Because technology and threats change, security requires continuous monitoring, testing, improvement, and informed judgement. Key TermsAsset: Anything valuable that requires protection. Attack: An attempt to compromise an asset or security property. Attack path: A sequence of conditions or actions leading toward compromise. Attack surface: The collection of possible interaction or entry points exposed to threats. Authentication: Verification of an identity or claimed origin. Accountability: The ability to attribute actions to responsible entities. Availability: Accessibility of information or services when authorised users require them. Confidentiality: Protection against unauthorised disclosure. Control: A measure that modifies security risk. Defence in depth: Use of multiple complementary security layers. Exploit: A method or code that takes advantage of a vulnerability. Integrity: Protection against unauthorised or improper modification or destruction. Least privilege: Granting only the authority necessary for an authorised task. Non-repudiation: Evidence supporting the origin or performance of an action. Risk: The possibility of adverse consequences arising from uncertainty. Secure by design: Incorporating security requirements throughout design and development. Threat: A circumstance or event capable of causing harm. Threat actor: An entity capable of carrying out a harmful action. Vulnerability: A weakness that can be exploited or contribute to harm. Trust boundary: A point where assumptions about authority, data, or security change. Review QuestionsShort Answer Questions- Define an asset and give three examples from a cloud-based information system.
- Distinguish a vulnerability from an exploit.
- What is the difference between authentication and authorisation?
- Explain the principle of least privilege.
- Name the three properties of the CIA triad and briefly define each.
Long Answer Questions- Explain how confidentiality, integrity, availability, authenticity, accountability, and non-repudiation complement one another.
- Discuss defence in depth and secure-by-design, including their benefits and limitations.
- Describe a systematic process for assessing the risk of an internet-facing service.
- Explain why attack-surface management must include people, suppliers, cloud services, and physical facilities as well as software.
- Discuss the ethical and governance responsibilities of a cybersecurity professional who performs security monitoring.
Analytical / Application Questions- A small business uses a public web server, shared administrator credentials, an untested backup, and a flat internal network. Identify four assets, four vulnerabilities, two plausible attack paths, and a prioritised set of controls.
- A hospital wants to maximise availability by permitting all staff unrestricted access to clinical systems. Analyse the security conflict and propose a design using least privilege, availability controls, and accountability.
- A university detects that a valid user account downloaded a large number of confidential files at night. Analyse the relevant security properties, evidence required, possible controls, and ethical limits of the investigation.
Multiple Choice Questions with AnswersQuestion 1Which statement best distinguishes a vulnerability from an exploit? A. A vulnerability is a weakness; an exploit is a method used to take advantage of it. B. A vulnerability is a security control; an exploit is an asset. C. A vulnerability is an attack outcome; an exploit is a threat actor. D. A vulnerability is a legal obligation; an exploit is a risk register. Correct Answer: A. A vulnerability is a weakness; an exploit is a method used to take advantage of it. Question 2Which security property focuses primarily on preventing unauthorised disclosure? A. Integrity B. Availability C. Confidentiality D. Accountability Correct Answer: C. Confidentiality Question 3What is the principal purpose of least privilege? A. To give every user administrative access B. To limit authority to what is necessary for authorised work C. To eliminate the need for authentication D. To ensure systems remain permanently available Correct Answer: B. To limit authority to what is necessary for authorised work Question 4Which example is primarily a detective control? A. Centralised monitoring of protected audit logs B. Disabling unused network services C. Encrypting a backup D. Requiring a security policy signature Correct Answer: A. Centralised monitoring of protected audit logs Question 5Which situation most clearly represents an attack surface? A. A list of approved security policies only B. All possible systems, interfaces, devices, and processes through which interaction could occur C. The financial value of an organisation D. A completed incident report Correct Answer: B. All possible systems, interfaces, devices, and processes through which interaction could occur Question 6Which statement about authentication is correct? A. It determines all permissions after login B. It verifies an identity or claimed origin C. It guarantees that a user is trustworthy forever D. It is identical to data encryption Correct Answer: B. It verifies an identity or claimed origin Question 7A system has an internet-facing obsolete component, excessive administrator permissions, and incomplete download logs. Which response best reflects defence in depth? A. Install one additional antivirus product and make no other changes B. Remove or update the component, reduce privileges, improve logging, and segment the system C. Publish the administrator password so actions are transparent D. Disable all backups to reduce exposure Correct Answer: B. Remove or update the component, reduce privileges, improve logging, and segment the system Question 8Which statement about the expression Risk ≈ Likelihood × Impact is most accurate? A. It is a universal physical law with no assumptions B. It is a practical decision model whose scales and assumptions must be defined C. It proves that low-likelihood events can always be ignored D. It measures only technical vulnerabilities Correct Answer: B. It is a practical decision model whose scales and assumptions must be defined Question 9What does secure-by-default mean? A. The initial configuration uses safer settings and requires explicit justification for additional exposure B. Users receive all permissions until an incident occurs C. Security is added only after deployment D. Every system must be disconnected from the internet Correct Answer: A. The initial configuration uses safer settings and requires explicit justification for additional exposure Question 10Why are shared administrator accounts a weakness? A. They prevent any administrative action B. They make encryption impossible C. They weaken accountability by making individual attribution difficult D. They guarantee that availability will be lost Correct Answer: C. They weaken accountability by making individual attribution difficult
|