Software Development Security

1.1 Where vulnerabilities live: ring model and OSI stack

Domain 3 introduced the ring model to show how layers of function stack up to produce the systems and information architectures organizations depend on. Hardware carries its own software, firmware, burned into ROM. Operating systems drive families of hardware through device drivers, without the OS having to handle low-level details. That is exactly the logic of OSI Layers 1 and 2: they encapsulate hardware details and expose to higher layers the functions they need. Layer by layer, the system builds up to Layer 7, where the user and their applications consume services rendered by software running on many different systems.

The key point for the exam: each layer depends on lower layers for its encapsulated security controls, but it also INHERITS their vulnerabilities. If an exploitable error exists in a lower layer (firmware, driver, network stack), every layer above inherits it, knowingly or not. Conversely, the inner (or lower) layers of the ring or stack must be protected from the consequences of attacks targeting vulnerabilities above them. Security is therefore never the business of a single layer: it is vertical defense in depth.

Software exists at every level of the ring, and that software often depends on configuration files, scripts, and initialization (default) values. A typical application program may comprise tens of thousands of files of executable code, parameter data, scripts, and other data. Each of these files is a potential risk surface: vulnerability hides not only in code, but also in the configuration and data that drive that code.

1.2 Threat modeling and STRIDE

Threat modeling, as defined by OWASP, is the security process by which potential threats - or the absence of safeguards - are identified, categorized, and analyzed. Concretely, you create abstractions of the system to spot the boundaries (perimeters) between subsystems and between the system and its external environment. Software, hardware, data, and people are all crossing points of those boundaries. Threat modeling means looking at an environment, system, or application from the attacker's viewpoint and determining the vulnerabilities they might exploit.

The most widespread model is STRIDE, a mnemonic for six threat categories: Spoofing (impersonating an identity), Tampering (modifying something on disk, network, data, or code), Repudiation (denying having performed an action), Information disclosure (exposing information to someone unauthorized), Denial of service (exhausting or degrading a service), and Elevation of privilege (gaining privileges without authorization). With STRIDE, the professional decomposes the system into relevant components, analyzes each component's susceptibility to those threats, then identifies mitigations. Other models pursue the same ends: PASTA, LINDDUN (privacy-oriented), and Trike.

The threat surface is the total of crossing points for a given boundary: TCP/IP ports, login services, query fields on a web page, attachment points for removable media. Each crossing is an opportunity to apply a control technique within an overall risk mitigation strategy. Data-centric threat modeling (NIST SP 800-154, 2016) shifts the focus from the system to the data: it models the authorized movement, locations, execution, and input/output of data, which maps directly to protecting data in transit, at rest, and in use.

Classic exam trap: threat modeling serves to IDENTIFY, CATEGORIZE, and ANALYZE threats. It is NOT mitigation. Mitigation is the step that follows, not a step of threat modeling itself. Confusing the two is a frequent multiple-choice error.

1.3 Mobile code and executable content

Web applications expand the threat surface by extending our systems' architecture with mobile code, also called executable content. Mobile code is a file (or set of files) sent by one system to one or more client systems; once opened by software already installed on the client, it controls the execution of the client's software or is directly executed by the client's CPU. The historical distinction is sharp: traditional client-server architectures kept code in place (different functions on clients and servers) while only data moved. Web architectures, by contrast, DEPEND on mobile code to work.

Each time a browser connects to a server, the server downloads onto the user's machine files containing the control logic and data needed to render the page, provides input fields, validates those inputs, and sends data back to the server. Mobile code comes in many types: the most common are JavaScript, Java Archive (JAR files), XML files, and API requests. The HTML files of the page itself and CSS style sheets are also executable content. Apps, applets, widgets, add-ons, and browser add-ins are further examples. Bots are an emerging class: they use limited machine learning capabilities to assist user requests, automate workflows, or validate input quality.

Nearly every action through a web app opens both the client's threat surface AND the server's: the mobile code sent by the server must cross the client's threat surface to be rendered, but data entered in fields and returned by a submit or post - which can itself be mobile code - crosses the server's threat surface. Remember: nearly all species of malware are mobile code, or executable content, or exploit the built-in systems and architectural features that make mobile code possible. Mobile code is therefore not one risk among many: it is the very mechanism most web attacks hijack.

1.4 The software environment and the three temporal perspectives

The software environment, broadly understood, gathers all the elements, activities, information, people, and systems that affect how software is created, used, modified, and ultimately disposed of. This environment may be limited to an organization that is the sole creator and user of its software, or span an entire market for COTS (commercial off-the-shelf) software. It includes anyone who can read or reverse-engineer the code, its users, and even those affected by the software without using it directly. It often encompasses legal, regulatory, and external factors. Telling example: during the COVID-19 pandemic, patients could access telemedicine only once the software environment for medical insurance billing had been modified to allow it. The software environment is thus complex and reaches far beyond code alone.

The life cycle model adds another source of complexity: three different temporal perspectives. First, design and development: this is where the most self-inflicted vulnerabilities are created, which may go undetected at test and assessment. The threat surface here is smaller and easier to control than at any other stage. This phase can last days, months, or years.

Second, runtime during operational use: both the individual moments of use by each user, and the days, months, or years a given version is made available. This is when the threat surface is MAXIMAL and risk control is hardest for developers, maintainers, and security teams. Third, after one version is replaced or retired by another: the system expands with each new version and each local adaptation. Discovery of a vulnerability in any version still in service can endanger the latest edition as well as earlier ones. This overlapping-support phase often spans years. Exam takeaway: the threat surface is not constant - it is minimal at design, maximal at runtime, and persists as long as older versions remain deployed.

1.5 The time/quality trade-off and the cost of late changes

For decades, organizations believed in a dilemma: get software fast and cheap but sacrificing critical functions like security, or later, more robust and secure, but at far higher cost. The birth of the internet reflects this choice and the implicit belief that no middle ground existed. It is a false dilemma: most exploitable vulnerabilities are self-inflicted, created as errors in requirements, design, and code, and left undetected by errors in testing, verification, and assessment - then left for an attacker to find and exploit. Many organizations have avoided this false dilemma by choosing approaches that satisfy business needs with reliable, resilient, and secure software.

The economic reason is the rising cost of late change. When an error is found and fixed in the phase where it was introduced, its cost is the baseline: "1x." Found one phase later, the cost rises; found in operations or maintenance, it explodes - not only because of rework, but because it then impacts business and mission objectives. The curve runs from 1x to near-exponential growth. Jumping straight from idea to code (construction-only) looks cheapest but is not: the more deliberate, front-loaded analysis of security, reliability, and safety is well worth the effort.

Much of these defects come from data. Classic errors persist: poor handling of loops and conditionals, wrong data types, misuse of one module's data/code by another, poor handling of special cases and exceptions, incomplete parameter sets between modules. The central problem: input data out of range, incomplete, or in range but incorrect causes abnormal behavior. Hence the phrase "garbage in, garbage out" - running an activity with no effective control of data quality.

NIST Draft SP 800-154 - Guide to Data-Centric System Threat Modeling (2016) establishes data-centric threat modeling as a methodology: it focuses on the authorized movement, locations, execution, and input/output of data, which maps to protecting data in transit, at rest, and in use. It reminds us that poorly controlled input can expose other data, allow arbitrary code execution, corrupt storage, or terminate the application; and that misuse of system utilities to read or extract data can be a step in exfiltration. Key principle for the exam: protecting the INFORMATION in the system is the end; protecting software, hardware, people, and premises are only the means.

2.1 The classic waterfall SDLC: SLC vs SDLC and its phases

The classic software development life cycle (SDLC), born in the 1950s and institutionalized in government acquisition standards such as the Department of Defense's MIL-STD-2167, is the waterfall model. When people say 'the SDLC' without qualification, they almost always mean this waterfall model. It is a serial, phased approach where each phase is completed and documented before the next begins; the transition between phases is marked by a formal decision event, often a milestone or approval, with identification, status accounting and managed resolution of remaining open items. Each unresolved item represents a risk to the program.

The generally accepted waterfall phases are: project initiation and planning; functional requirements definition; system design specifications; development and implementation; documentation and common program controls; testing and evaluation control (certification and accreditation); transition to production. As the word 'development' implies, the SDLC ends at implementation (placing into production). The system life cycle (SLC) covers the entire life of the system and adds two phases beyond that: operations and maintenance support (after installation), then decommissioning/disposal and system replacement.

Exam trap: do not confuse SLC and SDLC. The SDLC ends at placing into production; operations & maintenance and decommissioning belong to the SLC, not the SDLC. Another trap: in a strict waterfall, the later an error is found, the more its fix cost explodes - the maximum impact occurs in the operations & maintenance phase. This justifies the front-loaded analysis and testing effort of waterfall for high-reliability systems (nuclear, space, aviation).

2.2 Security at every phase of the SDLC

Security is not a phase: it runs in parallel with every phase of the methodology. In project initiation and planning, the project justification is endorsed by management (objectives, scope, cost, schedule); understanding the security requirements begins here, and security activities proceed in parallel. In functional requirements definition, you formalize functional AND nonfunctional requirements (security, reliability, safety) with all stakeholders (owners, compliance, privacy). Beware: waterfall struggles with nonfunctional requirements and emerging properties, which can only be assessed by analysis - ignoring them is a reasoning fallacy. In system design specifications, you design the architecture, outputs and interfaces; data flows (input, data flow, output) and security features are built into the design. In development and implementation, code is written (from scratch, approved libraries, snippets); you need coding standards, validated libraries, strict code reuse rules, and above all time allocated to code review before moving on.

The acceptance phase is a formal, structured handover to the customer, measured against the agreed requirements specification baseline. Several independent teams may step in: IV&V (independent verification and validation) examines, tests and analyzes the system at the customer's direction, focusing on selected requirements or critical elements; SV&V (selected/specialized verification and validation) specifically targets security, reliability, safety or other emerging properties; OT&E (operational testing and evaluation) evaluates the system as the operations team will actually use it, with concepts and procedures provided by the customer. Risk caveat: the further these independent teams stray from contractual requirements, the more the issues found are costly surprises to fix.

Transition to production does not belong to traditional waterfall (performed by the customer organization): security accreditation, user training/awareness, installation, data conversions, sometimes parallel operations. Operation and maintenance (an SLC phase): monitoring, continuity, redundancy, defect correction, testing backup/recovery procedures, and periodic recertification - especially upon significant changes (data classification, physical environment, new hardware/OS/software, new external interfaces). Decommissioning: withdrawal from service and proper disposal of hardware and software. Trap: a maintenance change must never disable or weaken a required existing security control.

2.3 Iterative and other models: from structured programming to cleanroom

Strict waterfall proved too rigid: on multi-year programs (FAA, DoD's WWMCCS) the real world moved on before test entry and the requirements baseline was no longer valid. Iterative development answers this by allowing successive refinements of requirements, design and code, provided a change control mechanism and a controlled scope. Security risk: in a changing environment it is hard to guarantee that security provisions remain valid - if anything changes, security requirements may need to change too. The Spiral method is a nested version of waterfall: each phase is run as a waterfall, but four substages based on the Deming PDCA cycle (Plan, Do, Check, Act) are added to it. The key novelty: a risk assessment review (the Check) at each phase, with cost/schedule revision and a continue/cancel decision point each turn.

Several 'lean' models speed up production. RAD (Rapid Application Development) is a refined form of prototyping with strict time limits per phase and efficient tools; risk: decisions made too fast leading to poor design. Prototyping builds a simplified version of the application, has it reviewed, folds in feedback, and iterates until the owner is satisfied. The Modified Prototype Model (MPM) is a refined form ideal for the web: basic functionality deployed fast, maintenance chained right after, the application evolving with the organization rather than frozen. The Reuse model builds the application from already-tested existing components (ideal in OO); it is arguably the most widespread approach yet often the most poorly managed. Component-based development assembles standardized building blocks already tested for security (largely replaced by OOP).

Other methods round out the picture. Structured programming (1970s, before OOP): heavy use of reused subroutines and block structures, discipline, reviews/approvals at each phase - still-sound principles but rarely used as-is. JAD (Joint Analysis Development): facilitation techniques involving all stakeholders at each critical phase. The Exploratory model: requirements built with available resources and many assumptions - security must be prioritized because structure is lacking. CASE (Computer-Aided Software Engineering): automation via formal languages at each step with a database linking phases (Space Shuttle Mission Control) - fell out of use. Cleanroom bets on defect prevention rather than defect removal: write the code correctly the first time, quality through design - the same logic as 'security baked in'. Extreme Programming (XP): values of simplicity, communication, feedback; developers always working in pairs; small fully-integrated releases; owners and security involved in defining needs ahead of developers.

Exam trap: Spiral = nested waterfall with PDCA and a risk review at each phase (not to be confused with a plain iterative model). Cleanroom = defect PREVENTION (not removal/correction).

2.4 Agile, Scrum and DevOps

Agile development answers teams and needs that grow and evolve: it favors small team environments, collaborative iterative learning, building, testing and deploying operational capabilities. Its patterns - Scrum, sprint, or SAFe - manage change and produce working, reliable, verifiable functions. A sprint is a short, time-boxed cycle producing a deliverable increment. Agile can handle security considerations well, provided the agile team works effectively with information security experts. Recall from module 1: Agile delivers more working software, faster, but is rightly criticized for not delivering better quality or more secure software by default.

DevOps combines 'development' and 'operations' (and typically quality assurance). Built on lean/agile principles, it has business owners, dev, ops and QA collaborate to deliver software continuously, so the business can react quickly to market opportunities and customer feedback. Google, IBM, Amazon and Microsoft all have implementations driving their core business. DevOps rests on four common principles: develop and test against 'production-like' systems (capture realistic behaviors before production readiness); deploy with repeatable, reliable processes (automation is essential: continuous, automated, frequent deployment and testing, which lowers deployment failure risk); monitor and validate operational quality (move monitoring forward early in the cycle, with meaningful metrics captured at each deployment); amplify feedback loops (create channels so all stakeholders can access and act on feedback).

Exam trap: DevOps is not DevSecOps. DevOps prioritizes the rapid delivery of new versions above all else; security, safety and resilience are often deprioritized and delegated to other processes. It is precisely this gap that DevSecOps fixes (see next lesson).

2.5 DevSecOps and shift-left

While DevOps was becoming popular, organizations facing stricter security and safety requirements pushed a different approach. The term SecOps was coined to take the lessons of the classic waterfall and integrate security activities into every step of the process. Where DevOps prioritized rapid delivery at the expense of security, SecOps delivers more secure code by handling security requirements at every stage - at the cost of more time. DevSecOps merges these two models: it moves the security requirements leverage to the left of the timeline (the shift-left), giving each cycle turn earlier opportunities to address and deliver priority security needs into production.

Shift-left is the central idea: rather than auditing security after development (post-hoc), security activities - threat modeling, scanning, testing, monitoring - are moved into the upstream design and requirements phases. Comparing the DevOps diagram with the DevSecOps diagram shows the explicit inclusion of security concerns, activities and professionals throughout the pipeline. Key aspect: the development team (which should include security members) is responsible for security testing and for resolving security issues found during development and testing. Many organizations continually adapt DevSecOps principles to their culture, co-adapting culture and processes to become more security-oriented.

Exam trap (official Q8): DevOps = fast delivery, security delegated to other processes; DevSecOps = security integrated at every step via shift-left. If the question contrasts 'fast but security outsourced' with 'security integrated early and everywhere', the 'integrated at every step' answer is DevSecOps.

2.6 Cross-disciplinary approaches: IPT and IPPD

In the 1980s, many organizations implemented waterfall wrongly: separate teams per phase, with no one but the project management team having an overall view. After costly failures, it became clear that involving the right knowledge, experience and perspectives end to end is a better way to develop complex systems. Two cross-disciplinary approaches are commonly used: the Integrated Product Team (IPT) and Integrated Product and Process Development (IPPD).

An IPT is a team of stakeholders with varied skills working together to achieve a defined process or product. It draws from many disciplines across the organization and the business/mission area to engage diverse viewpoints consistently throughout the system life cycle. Its members provide enough representation from all stakeholders - owners, management, developers, designers, contractors, security professionals - to ensure effective collaboration achieving the required result. The core idea is stakeholder engagement and viewpoint diversity throughout development.

IPPD recognizes that, in many complex projects, the right choices of management methodology, manufacturing approach and test/verification strategy cannot be made while the project is still being thought through; high-risk technologies or unproven algorithms may need exploration via demonstrators before clear requirements can be specified. It is a management technique combining essential acquisition activities through skilled teams to optimize the design, manufacturing and supportability processes, from concept through post-production support. IPPD facilitates multi-skilled members working together via the IPT concept: representatives from all functional disciplines - engineering, manufacturing, management, finance, procurement, legal, security - brought together with a team leader to identify and resolve issues and make sound, timely decisions. Trap: IPPD optimizes both the product AND the processes (design, manufacturing, support), whereas IPT primarily aims for stakeholder diversity; IPPD relies on IPT as its building block.

2.7 Choosing a methodology: end-to-end security and risk trade-off

There is no universally superior methodology. The choice must be based on the organization's requirements: some models suit long, complex projects better, others short ones. An application may require specific activities to succeed, and the organization may need to meet standards or processes imposed by its industry or government. It is often wise to combine several models to properly develop requirements in a cost-effective way. Manual key point: it is not that a formalized SDLC must be used, but rather that the entire development process must involve security. The number and nature of the phases are not of primary importance.

The universal rule, valid across all models: security must be included from the start and maintained to the end - not only of the development process, but to the end of the system's full life cycle. The best security is always the one designed into the system, not added afterward.

Industries frequently change their minds about their most urgent development needs: sometimes new functionality several times a day, sometimes emphasis on security, safety or auditability. The methodology choice may be driven by management's perception of a competitive-advantage window or, conversely, of an accentuated risk/liability window - more than by other principles. The security professional must keep a sensitivity to these nonstop shifts in emphasis. Exam trap: the question 'when to involve security?' has the answer 'immediately, from the start' - never after initiation, coding or defining test criteria.

3.1 The SW-CMM and its five levels

The Capability Maturity Model for Software (SW-CMM) was released by the Software Engineering Institute (SEI) in 1991. Although software development has evolved greatly since, the model stays useful: it lets an organization measure its current development capability and formulate an improvement plan. The CMM centers on quality management processes and describes an evolutionary path from chaotic, unstructured processes toward mature, disciplined, optimized ones. Each step along the way should yield better, faster, cheaper software, where 'better' covers any quality measure leadership chooses to focus on, including security and safety characteristics.

The five levels follow a strict order. Level 1 Initial: good practices can be repeated but stay ad hoc, chaotic; success depends on individuals. Level 2 Repeatable: best practices are repeatable and rapidly transferred across organization groups, because they are defined to cross project boundaries; this is the basic project management level. Level 3 Defined: standard processes are formalized, all new development follows strict, standardized, well-understood and proactive processes. Level 4 Managed: quantitative, measurable objectives are set for tasks, numerical measures are calculated and maintained as a baseline, reducing deviations from objectives. Level 5 Optimizing: practices are continuously improved and optimized, feedback from one phase positively impacts the others; this is the continuous improvement focus.

Exam trap: do not swap Defined (level 3, standardized and documented processes) and Managed (level 4, quantitative measures). Remember the 'chaotic to optimized' progression and the distinguishing pair Managed = you measure, Optimizing = you continuously improve.

3.2 SAMM, BSIMM, and CMMI

The Software Assurance Maturity Model (SAMM) is run by OWASP. Developed in the late 2000s, it is an open framework that helps an organization of any size formulate and implement a software security strategy. An organization uses it to evaluate its existing software security practices or to build a security program in successive iterations. SAMM rests on four core functions: Governance, Construction, Verification, and Operation. These functions span a wide range of activities: product management, requirements gathering, architecture and design, quality assurance, deployment, and production operations. Each function breaks down into several security practices, and each practice is split into three maturity levels, from the lowest (unfulfilled practice) to the highest (comprehensive mastery of the practice).

BSIMM (Building Security In Maturity Model) plays a complementary but different role. It is a descriptive, observational model: it describes what real firms actually do regarding software security, measuring activities observed in the field. SAMM, by contrast, is prescriptive: it recommends what an organization should do to improve. The trap is confusing the two logics: SAMM says 'here is how to improve yourself', BSIMM says 'here is what others do'. You often compare your BSIMM score to an industry benchmark; you follow your SAMM journey as a roadmap.

Finally, CMMI (Capability Maturity Model Integration) is the generic successor of the SW-CMM. Where SW-CMM specifically targeted software development, CMMI generalizes and integrates the maturity approach across other domains (services, management, acquisition). For the exam, remember the lineage SW-CMM (1991, software) then CMMI (broader integrated model), and the SAMM/BSIMM distinction rather than CMMI internals.

4.1 Languages, translation, libraries, and IDEs

A program written in a source language must be translated into machine-executable instructions. We distinguish compiled languages (fully translated to machine code before execution by a compiler) from interpreted languages (translated line by line at execution time by an interpreter). Between the two, some platforms produce intermediate code: Java source is compiled to bytecode, then run by the virtual machine. The useful level cue for the exam is the generation scale: Assembly (a low-level language, processed by an assembler) is closest to the machine, where one statement maps to a single processor instruction; higher-level languages (compiled or interpreted) translate one statement into several machine instructions.

A software library is a repository of prewritten code: classes, procedures, scripts, and other programming elements the developer calls rather than rewriting. A library hierarchy exists: OS and hardware libraries (vendor-supplied, with digitally signed updates), programming language libraries (supplied by the IDE or tool sets), development frameworks (such as .NET), in-house, project-specific, or customer-specific libraries (proven code harvested from internal projects), and third-party open-source libraries. The latter range from reputable sources to code of uncertain pedigree (blogs, forums) that must be inspected for back doors, Trojans, or logic bombs before any reuse. Software reuse trades risk for time: reusing too quickly without inspection introduces an exploitable vulnerability; over-inspecting cancels the time saved. Junior programmers sometimes spend more time searching for a reusable snippet than writing good code themselves.

Programming tools (debuggers, build tools, source code editors, static code analysis tools, revision control, unit testing) are often bundled in an IDE (Integrated Development Environment). An IDE combines many tools in one environment: it typically includes a source code editor, build automation tools, and a debugger, and may offer a class browser, object browser, and class hierarchy diagram for object-oriented development. Source code analysis tools look for security flaws in source code (and sometimes compiled code); it is best to use them during the first development phases to fix errors close to where they are introduced. Finally, the sandbox protects execution of mobile code: it limits memory and CPU and isolates suspect code. In the Java model, the Java security manager enforces the sandbox limits; sandbox applets can perform only a set of safe operations, while privileged applets (signed by a certificate the user accepts) can run outside the sandbox with extended access to the client.

4.2 Application security testing: SAST, DAST, IAST, RASP

Several application security analysis approaches coexist and complement one another. SAST (Static Application Security Testing) analyzes source code without executing it: it looks for common programming errors, compliance with guidelines and templates, and error sources visible in the source. Because it does not run the code, calling it 'security testing' is a slight misnomer; however, it is easy to deploy, scales well, runs early in the writing cycle, and even helps with refactoring. DAST (Dynamic Application Security Testing) does the opposite: it executes the unit, module, or whole application and injects a variety of tests to drive the code beyond its limits. This is the fuzz testing approach, which runs tens of thousands of test cases against the application, where manual testing covered only a few.

IAST (Interactive Application Security Testing) is a hybrid approach: it brings testing to web and mobile apps, where SAST and DAST struggle. IAST works with agents embedded in the software under test, letting the engine inspect the application's logic down into the library routines it calls, checking they are used correctly. Its limitation is coverage of serverless applications using non-HTTP interfaces. RASP (Runtime Application Security Protection) is more of a protection tool: its agents and instrumentation in the code can terminate execution if a potential security violation is detected during testing.

These tools share common limits: many vulnerabilities (authentication problems, access control issues, insecure use of cryptography) are hard to find automatically; false positive rates are high (useful for fine-tuning the tools); configuration issues often escape analysis because they are not represented in code; and code that cannot be compiled is hard to analyze. The exam trap is the SAST/DAST pair: SAST is static, reads source code, sits early in the cycle (shift-left); DAST is dynamic, tests the running application via fuzz testing.

4.3 Separation and control of environments

Software development relies on three key environments: the development environment (where analysts and programmers write, compile, and initially test the application), the quality assurance environment (QA, where users and the quality team run functional tests, ideally on a configuration simulating production as closely as possible), and the production environment. Other environments exist (test, staging), but the security stake is the same: control how each environment accesses the application and data, then keep the environments separate and isolated. People working in one environment must be restricted to it: it is generally accepted that a developer should never have access to production. Blended environments combine one or more of these individual environments and are the hardest to control, hence risky.

Classic protection measures are physical isolation of each environment, physical or temporal separation of data, access control lists, content-dependent access controls, role-based constraints, accountability, and separation of duties. Virtualization generalizes this isolation: virtual environments are defined containing the right mix of virtual machines (with OSs, application platforms, and supports) for each configuration tested. All of this is simply applying least privilege to the security of the development process, the first necessary step toward more secure software.

To run a program you need a runtime system: the set of hardware and software components that lets an application run, whatever the language. Every language has a runtime system, whether compiled, interpreted, or invoked via API. The JRE (Java Runtime Environment) is the example: it comprises the JVM (Java virtual machine), the platform core classes, and the supporting libraries needed to run a Java program. The runtime system is also the gateway by which the program interacts with the runtime environment, which holds the state values accessible during execution. Finally, code repository security is an asset to protect like any other: a combination of logical and physical access controls, plus protection of the integrity and availability of the content. Offshoring development complicates this protection, since the code and environment may escape the enterprise's direct inspection.

4.4 Safer deployment: TCB, reference monitor, security kernel

The deployment phase offers security levers through the right choice of hardware, OS, and configuration. At the core of this security is the Trusted Computing Base (TCB): the set of hardware, software, and firmware components of an architecture responsible for supporting the security policy and object isolation. When designed and coded properly, all the system's security features form the TCB. It can contain trusted paths (secure communication channels between the user or program and the TCB, which the TCB protects from any compromise) and trusted shells (whatever happens in the shell stays confined to that channel).

The reference monitor is the element that enforces security between subjects (users) and objects (data or resources). It is an abstract machine that mediates, or controls, all access subjects have to objects, ensuring any subject trying to access an object holds the appropriate rights. The reference monitor is a concept; its concrete implementation is the security kernel. The security kernel is made of all the TCB components (software, hardware, firmware) and implements the reference monitor mechanism and the security policy. In a layered architecture, the kernel sits at the lowest, most primitive level: it is the small portion of the OS through which all references to information and all authorization changes must pass.

To be implemented correctly, the security kernel must meet three fundamental requirements: completeness (all access to information must go through the kernel), isolation (the kernel must be protected from any unauthorized access), and verifiability (the kernel must be proven to meet its design specifications). To measure confidence in the TCB's security capabilities, evaluation criteria are used, such as TCSEC (Trusted Computer System Evaluation Criteria) and the current Common Criteria. Above this core come cryptographic approaches: PKI (public key infrastructure) and digital signatures, certificate and key management, HSMs (hardware security modules) for robust key storage, and integration with access control and identity management. A negative rule applies: never let developers or administrators build their own cryptographic solutions. Policies must also cover shadow IT and BYOx (bring your own everything), often driven by citizen developers.

4.5 DBMS controls as software security

The DBMS (database management system) provides security controls to prevent unauthorized access and improper modifications by authorized users, based on identification, authentication, authorization, and accountability. The first mechanism is lock control: the DBMS controls who can read and write data by placing locks on rows or objects. When two processes try to access the same resource simultaneously and that resource cannot handle more than one request without breaking integrity, a deadlock may occur: the system cannot release the resource to either transaction and refuses both. To avoid it, the DBMS gives a write lock to one transaction (for example on the last seat of a flight) and queues the other. Locks can be granular: by table, row, record, or even field.

Other DBMS access controls complement locks. View-based access control logically divides the database: a trusted front end assigns each user type a view that hides unauthorized sensitive data, with possible granularity on rows and columns. Grant and revoke manages permissions: a user with grant authority can grant permissions to others; without the grant option, they cannot pass that authority on. The notable security feature is the revoke's cascade effect: revoking a user's rights also revokes all rights that user had granted. Metadata also acts as a gatekeeper: the data dictionary is a central repository of information about the enterprise's databases (sensitivity, classification); it does not directly control access but informs risk management.

OLTP (Online Transaction Processing) handles a high volume of real-time transactions against databases, with many concurrent users (airline reservations, finance, retail). It relies on the DBMS's concurrency and atomicity requirements (the ACID test: atomicity, consistency, isolation, durability). OLTP acts as a monitoring system: it detects a process abort, restarts it, and backs out a transaction if needed. Two important security features: the transaction log records a transaction's information before processing, then marks it processed; on failure, the transaction is recovered and reapplied via the log. Checkpoint restart uses the logs to restart the machine by replaying to the last checkpoint (last known good transaction), all following transactions being reapplied before reopening data access.

4.6 Configuration management, change management, and CI/CD

Configuration management (CM) means monitoring and managing changes to a program or its documentation. Its goal is to guarantee the integrity of the code, its availability, and use of the correct version of every component (code, design documents, documentation, control files). CM reviews every change through four activities: identifying (identify the changes), controlling (each change goes through documentation reviewed and approved by an authorized person, the change management or RFC, request for change), accounting (record and report the configuration throughout the procedures), and auditing (verify the change and ensure it does not affect the security policy). A CM plan defines the configuration items under CM, their naming, how they enter and leave the controlled set, how an item may change, and how CM tools enforce these rules. In a project, CM limits changes to the scope; failing CM leads to scope creep, where requirements change continuously and the project never finishes.

Software Configuration Management (SCM) applies these principles to source code: version control, branching, and merging that let several teams work without conflicts, plus stable builds. It is the right tool when an organization manages its versions poorly, unlike a plain document management system that offers neither branching nor merging.

Continuous Integration (CI) and Continuous Delivery (CD) automate and coordinate the pipeline processes, from writing code to running the finished software in production. The pipeline chains: coding a software unit, unit test, build and integration of units into subsystems, then into a complete application, followed by more testing, and finally deployment of the build package. The exam trap distinguishes the two: CI integrates and tests code frequently in the repository; CD deploys to production. Done well with strong security-team involvement, CI/CD are major building blocks of a DevSecOps approach, making change management more seamless, auditable, and enforceable. Two security challenges: the CI/CD chain itself must pass a security assessment, and it can feed the pressure to deliver faster at the expense of security. Finally, control granularity must address both program and user: if a user cannot access object X but has a program that can, the security mechanisms are bypassed (low granular system). The answer is least privilege, separation of duties, and reasonable access limits.

5.1 Balancing assurance, cost, and business needs

Assessing the effectiveness of software security is, first of all, applied risk management. Every step, from the birth of an idea to the system's retirement, aims at attaining sufficient confidence: the software is secure enough, safe enough, and fast enough for users' needs, and stays within budget and schedule. Because systems are increasingly distributed and rely on shared open protocols, interfaces, and open-source code, the trade-off between breach risk and the complexity, difficulty, and cost of building more securely grows harder every day.

The security professional is only an advisor: security does not dictate what the business does, it lets the business operate safely. To compare risk to business needs, the organization follows four steps. Discover: consult stakeholders (interviews, questionnaires, working groups) about what they do and the tools they use; this phase often must be repeated to get consistent answers. Evaluate: assess those answers, because leaders rarely articulate clearly what they do and the answers are often wrong. Agree: form assumptions to reconcile the views; if all parties agree, produce the business plans. Document: record the process and plan, which become the working model.

Exam pitfall: this four-step process does not consider risk - it reflects what the business says it needs. Once the decision is made and implemented, it falls to the security team (apart from the security architect) to make the plan secure. To steer all this, the principle 'if you can't measure it, you can't manage it' demands robust configuration management (CM) and configuration control (CC) processes: without measurement, there is no security management.

5.2 Auditing and logging of changes

Change management and change control must first decide at what level of granularity the system elements are defined, enumerated, managed, and controlled. This establishes the set of configuration items (CIs) formally subjected to CM decision-making and to CC enforcement and audit. The whole process depends on the system's other security processes to rigorously prevent tampering with the contents of a CI.

A software CI must be uniquely identifiable, and that identifier is linked to the version control processes used during integration and delivery. Enumerating the system must reveal the precise CIs and their version identification. Without this specificity and granularity, enumeration loses its ability to produce audit-worthy findings: you cannot claim a system matches its baseline if you do not know exactly which versioned elements compose it.

Change control traditionally relies on change logs, fed by file-system and application logs kept by the OSs, by CM/CC system agents, or other means. Audits then step through these change logs to verify that the result of all logged changes matches the enumerated baseline of the current system. Exam pitfall: an audit does not merely observe that changes happened, it verifies that they bring the system back to the expected authorized state (the baseline). This is how you assess security effectiveness through auditing and logging - the answer to the 8.3 profile scenario.

5.3 Software assurance: process, result, and assessment types

Software assurance (or software quality assurance) establishes that a system: performs all intended and required functions; performs no unintended or unauthorized functions; is free from security vulnerabilities, exploitable or not; and is protected against insertion of errors in design, code, form, function, and data at any time in the life cycle. It is both a process - the planned, systematic set of activities to gather data about the software, evaluate it, and determine its overall quality - AND a result: the confidence stakeholders can have in the software's ability to fulfill their needs securely. This confidence is comparable to a warranty of fitness.

Many security needs are poorly evaluated by software quality assurance because analysts treat them as nonfunctional requirements. Functional requirements are the specific things the system must do (correctly process a purchase transaction): code is written to accomplish them. Nonfunctional requirements are characteristics of overall form or attributes of behavior that result from the design; most security requirements have been considered nonfunctional - no specific code is written because there is no 'function' to carry out. Security is also an emerging property: it stems from the whole design rather than an isolated module. Effective processes are organized around workflows (tasks, triggers, reporting) and metrics based on use cases, which are security-performance benchmarks in known situations.

There are four types of software risk assessment to know. Certification and accreditation: upfront analysis of needs, requirements, and design, with acceptance testing against the baseline; costly, it is falling out of favor. Risk management frameworks: NIST, ISO, and other formalized frameworks covering the whole risk decision cycle. Software process CMMs: SEI models characterizing business processes end-to-end by their reliability, repeatability, and achievement of quality metrics. Software quality assurance (software assurance): like C&A, it establishes how well the software meets its requirements without exposing the organization to undue risk. The common thread is a due-diligence question: what confidence can we have that the software is safe, secure, and fit for use?

5.4 Certification and Accreditation (Security Authorization)

Certification and accreditation, sometimes called Security Authorization, separates two distinct decisions. Certification is the formal process of evaluating the security capabilities of the software or system against a predetermined set of security standards or policies; it can also examine how well the system meets its security-related functional requirements. In other words, certification is the comprehensive technical security analysis of the system, whose result contains an analysis of technical and nontechnical security capabilities and countermeasures and the extent to which the system meets the requirements.

Accreditation is the formal management decision regarding the results of certification, used as authorization to move into production. It usually requires a designated accrediting authority (DAA) to review and approve, authorizing the system in production for a specific period. Exam pitfall: certification = technical analysis (the 'what' and 'how' of security); accreditation = management decision/authorization (the business 'go'). Management may accredit a system that failed certification, or refuse to accredit a system certified as compliant - the final decision is managerial, not technical.

There are two types of accreditation. Provisional accreditation applies for a specific period and lists the changes required to reach full accreditation. Full accreditation implies that no changes are required for the decision. For valuable testing, the application must be tested in an environment that simulates production as closely as possible, testing security capabilities and simulating security problems that may arise - this is the first phase of the C&A process. Usage: mostly government environments (and their customer agencies), which have strict C&A and authorization-to-operate requirements; most commercial organizations see no benefit against the administrative burden.

5.5 Testing, verification, and security assessment

Testing uses a system (or its components) in a scripted, controlled way to verify that a set of inputs and initial conditions produces the required results. It occurs at many steps to verify correct design, correct implementation, and fitness for use, including security characteristics. Acceptance testing (originally 'functional testing') is a formal test conducted by the customer's end-user teams to decide whether to accept the system: it answers 'can we use it for our business needs?'. It differs from unit tests, written and run by the developers themselves, which answer 'does it behave according to functional requirements?'. Each test (a case) yields a pass or fail; accepting a system with known discrepancies and a resolution plan is common.

Regression testing verifies that a change or addition has not negatively affected existing functionality: catching bugs accidentally reintroduced in a new build and ensuring already-eradicated bugs stay eradicated. Security regression testing verifies that a new set of modifications has not re-exposed the system to previously known exploitable vulnerabilities - sometimes a security patch undoes the mitigations of a previous update. Security assessment testing, including ethical penetration testing, applies throughout the operational life span; it evaluates the system's present state and actual use, which has often evolved beyond the original requirements, and inspects that designed-in security controls still work against current threats.

Test data best practices are exam classics. Never use production data (privacy, need-to-know); if unavoidable, the data owner must sign off and strict usage controls are negotiated. Include data at the edges of acceptable ranges, in between, and beyond what is expected, with fuzz testing (random, not 'expected' data). Also test with known good data to verify expected behavior. Do bounds checking of field size, time, and date to prevent buffer overflows. Sanitize test data so sensitive data is not exposed to unauthorized testers. Review data before and after each test, and always maintain clear segregation between test and production environments.

Tests are also classified by how much internal knowledge the tester has. Black-box testing assumes no knowledge of internal code and exercises the system from the outside (close to DAST and external pentest). White-box testing has full access to source code and design (close to SAST and code review). Grey-box testing combines both: partial knowledge (for example accounts or schemas) to focus the tests. Choosing the right mix by risk and criticality strengthens coverage.

6.1 Acquisition via third-party development: the four phases

When an organization contracts a third party to develop a system, customize existing software or tailor a commercial platform, the acquisition process becomes the lever to enforce software assurance. Security must be designed in from the start: the best security is always engineered into the application, not bolted on afterward. The contract's nature (open-ended or fixed) reflects the uncertainty in development, test and acceptance test; a fully fixed contracting baseline is often overly optimistic because few software projects ship on time, within budget and with all requirements met.

Software assurance during acquisition follows four phases. (1) Planning: identify the need, do sizing/scoping, run risk assessments, compete alternative implementations, estimate ROI against the internal hurdle rate (a project not exceeding this minimum return needs an overriding reason to be approved), then write the software requirements into the Statement of Work (SOW) and an acquisition strategy with bidder screening criteria. (2) Contracting: issue the solicitation or Request for Proposal (RFP) with the SOW and terms and conditions (acceptance conditions, prequalification, certifications), evaluate proposals, then negotiate and award the contract. (3) Monitoring, acceptance and deployment: set the work schedule, apply change management / configuration control, and review and accept deliverables - assurance case deliverables must prove compliance with the contract's risk mitigation strategies. (4) Ongoing use and support: sustainment (risk management, assurance case management, change management) then disposal or decommissioning.

Exam trap: a vendor claiming a high CMM is not automatically secure. Most CMMs do not explicitly address safety and security; a supplier with mature process capability may still fail to exercise practices critical to software assurance. The security professional must verify that software assurance is genuinely built into the supplier's process capabilities, matching the organization's risk mitigation needs.

When the organization depends on bespoke software whose source code it does not own, a software escrow protects continuity: a trusted third party (escrow agent) holds the source code and documentation, and releases it to the customer under predefined contractual conditions, typically vendor bankruptcy, end of support or a serious breach. It is a key supply-chain control to negotiate during the contracting phase, alongside the SOW and the assurance case.

6.2 Open source and orphaned systems

Open-source software is source code made available to everyone, usually developed by and for the community under varied licenses to drive adoption. Advocates believe openness improves security, expressed in Linus's law: with enough eyeballs on the code, all bugs become shallow. The idea is that review by other developers quickly finds and fixes vulnerabilities. Critics counter that nothing guarantees every flaw will be found, no matter how many reviewers; releasing the code does not remove vulnerabilities, and automatically assuming reliability creates a false sense of security. Dishonest programmers may find flaws without disclosing them, sometimes to exploit them or blackmail the vendor.

The debate is unsettled, but one principle holds: security by obscurity does not work. Hiding a technology does not protect it for long. Whether a program ships as source or only as an executable, observation, reverse engineering, disassembly, trial and error and random chance can reveal vulnerabilities. Open source is therefore neither inherently safer nor inherently more dangerous: it requires its own assessment.

A special case is orphaned software. An organization sometimes gets stuck with elements the original manufacturer no longer supports and for which no effective third-party support exists. In 2019 and 2020, UK doctors' offices had to stay on Windows XP because replacing XP-dependent clinical devices was beyond budget. Exam trap: do not confuse legacy with orphaned. A legacy system is still supported (in-house or by a third party) and remains, within reason, remediable. A technological orphan is generally unsupportable; it must be replaced or abandoned. Even without source code or documentation, assessment is still worthwhile: CVE data reveals potential vulnerabilities that can sometimes be mitigated by other means. Ultimately, refactoring the entire business process that depends on the orphaned technology is often the best bet.

6.3 Mergers and acquisitions: inherited risks

In a merger or acquisition (M&A), the new owner inherits both the good and the questionable assets of the absorbed organization: information systems, IT infrastructure, data and people. Security assessment of the combined architectures is hard. Organizational culture differences translate into different documentation expectations and standards, which can make incompatible or incomplete the configuration management and baseline identification, the asset inventories (enumeration of systems, software licenses, revision levels) and the risk inventories with their control strategies.

The riskiest unknown is often invisible: the acquired organization may carry an undocumented legacy of data breaches, intrusions, malware and compromised identities/access-control information. Tacit knowledge of these risks may already have walked out the door with employees who left before the takeover. The Marriott case (2016-2020) illustrates this trap: by absorbing the operations and IT infrastructure of other hotel chains, the company inherited pre-existing exposures.

Exam trap: security is rarely a priority in an M&A. The acquiring organization faces intense cost-control pressure to absorb and make the new business profitable, and has little appetite for allocating resources to a thorough security assessment of properties under consideration. The security professional must anticipate: require security due diligence before signing, and treat inherited identities and incompatible CM as first-order risks, not as a post-merger detail.

6.4 Commodity systems and COTS: due diligence

The vast majority of software in use within an organization are commercial products sold or licensed as commodities: these are COTS (commercial-off-the-shelf), firmware or embedded products - motherboard or controller firmware, OSs, standalone applications, productivity suites, application platforms. The organization is just one of thousands of customers and almost never has the capital to influence the developer to meet its specific security needs. Being one-size-fits-all by nature, COTS security is often too generic, or simply nonexistent.

The security professional is not helpless, though: the choice of product, and even of reseller, can and should be influenced by security considerations. Exploit CVE data - for the target product but also for other products from the same vendor. Research the vendor's reputation: responsiveness to vulnerability reports, speed of issuing updates, and use of signed update packages to distribute them. The same due care that keeps the system safe in operation should serve as due diligence before endorsing the decision to buy, lease or license it.

Exam trap (CYU 8.4): is COTS more dangerous than bespoke software written in-house? The expected answer is yes: its one-size-fits-all nature increases the potential for security faults, because security there is generic or absent. It can be considered, but only after a thorough risk assessment. Do not fall for the reverse reasoning ("COTS has necessarily gone through rigorous testing"), which is false.

6.5 Managed services and cloud: shared responsibility

Managed services let an organization focus on its core business, free up internal IT resources and obtain capabilities that would otherwise have required internal teams. Providers are third parties called managed service providers (MSPs). Possibilities are many: an ERP (enterprise resource planning) system is one example; a provider specialized in security monitoring and incident response is a managed security service provider (MSSP).

Cloud services deliver capabilities on demand over the internet, sparing the customer from acquiring and maintaining the infrastructure. As-a-service offerings include Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). In all these models, security and compliance are a shared responsibility between provider and customer: the higher toward SaaS, the more the provider owns the stack (hardware, runtime, application); the lower toward IaaS, the more the customer keeps responsibility (OS, middleware, data, configuration). Benefits are efficiency, cost reduction, flexibility and on-demand scalability; the most notable for the business is the shift from capital expenditure (CapEx) to operational expenditure (OpEx).

Exam trap: shared responsibility does not mean the provider owns all security. In IaaS, the customer remains responsible for the operating system, the data and the configuration; a misconfigured storage bucket is the customer's fault, not the provider's. Know where the responsibility line sits for each SaaS / PaaS / IaaS model.

6.6 Supply chain: SCA and SBOM

The objective-8.4 reasoning - we depend on software we do not write - extends into modern software supply chain risk management. An application is no longer a monolithic block: it aggregates dozens or hundreds of third-party and open-source components (libraries, frameworks, containers). Each brings its own vulnerabilities and its own licenses. Managing this risk requires knowing precisely what you ship.

Software Composition Analysis (SCA) is the tooling that automatically scans a project's dependencies to identify third-party components, correlate them with known vulnerabilities (CVE) and flag license issues. It extends the CVE logic of COTS due diligence, but applied to the product's internal components rather than the whole purchased product. The Software Bill of Materials (SBOM) is the formal, machine-readable inventory of all those components and their versions - a software nomenclature. Its purpose: when a major vulnerability hits a widespread library, the organization can query its SBOMs to know within minutes which products are affected, instead of auditing code blindly.

Exam trap: do not confuse SCA with SAST. SAST (static application security testing) analyzes your own source code for defects; SCA analyzes the third-party components you reuse. SBOM is not a scanning tool but an ingredient list; that transparency is what makes supply-chain incident response fast and reliable.

7.1 From source code to executable code

The development process translates users' ideas into a set of instructions and data that a computer executes. This translation stacks several layers, each moving away from the users' "business speak" toward the binary digits manipulated by hardware. Four forms of code structure this descent. Source code is a set of statements written in human-readable form (words, numbers, operators, punctuation) following the syntax (structure) and semantics (meaning) of a given language; many correct, complete source programs can implement the same design. Executable code, also called object code, is the binary representation of the machine instruction set the CPU and target hardware execute directly.

Intermediate code sits between human-readable source code and the binary values loadable into memory. Its main use is machine independence or portability: since CPUs have different instruction sets, specialized software (a runtime engine) is required for each CPU type. Java P-Code (bytecode) and Microsoft's Common Intermediate Language (CIL) are the two canonical examples. Arbitrary code, by contrast, is not a form of language: saying a vulnerability enables "arbitrary code execution" only means the attacker can fool the CPU into executing a different instruction set than the designers intended.

Translation tools are grouped by what they produce (Figure 8.13). Assemblers translate one statement into one machine instruction and produce files of executable code (.exe); benefits: source-code protection, repeatable execution, direct hardware view, fast execution. Compilers translate one statement into many instructions, also producing .exe; business-logic-oriented view, moderate speed. Interpreters translate one statement into many intermediate opcodes as real-time streams, translated at runtime (Java runtime system); key benefit: increased portability across architectures and statement-level debug/traceback. Exam trap: most exploitable vulnerabilities are introduced at the source-code level (errors translating design into the language), rarely by the tools themselves - even though malware-infested versions of these tools do exist.

7.2 Making machines execute instructions

In the early days of programming, developers coded the object (machine or binary) program directly, writing opcodes in binary and loading those strings into memory for execution. Assembly language made this easier: there is a direct correspondence between assembly mnemonics and specific opcodes (MOV for move, CMP for compare, DEC for decrement, ADD), but the files are formatted in a relatively readable way rather than as strings of hexadecimal or binary numbers. Assembly is called low-level because one line (one statement) translates, in almost all cases, into a single machine instruction, and it is specific to a given CPU.

High-level languages raise the level of abstraction: their source code is more comprehensible to people. A skilled programmer expresses complex operations concisely, and if they follow standard coding frameworks, the code stays legible and therefore maintainable. Figure 8.14 summarizes the paths from human idea to machine execution. Compiled languages (FORTRAN, Modula) require two steps: write the readable source code, then compile it into object code (sometimes via linkers and utilities); the source cannot be run directly. Interpreted languages shorten the cycle: the interpreter translates source into machine language at the moment of execution.

The trade-off is clear. A compiled program is native for the CPU, runs directly from object code and therefore runs far faster; some compilers also optimize the code. An interpreted program pays in performance because translation is redone each run, but gains portability: as long as an interpreter exists for the target platform, the application runs on varied machines (scripting languages are the example). Exam trap: do not confuse "compiled = fast but platform-bound" with "interpreted = portable but slower"; the exam regularly tests this speed/portability opposition.

7.3 Procedural vs object-oriented and language generations

Two ways of thinking about work structure programming. Procedural thinking reasons in sequences of steps (with conditional branches, loops, sequence controls): procedural programming emphasizes the logical flow of steps. A procedure is a set of software performing a specific function, requiring specific inputs and producing defined outputs (including error signals), and can call other procedures. Object-oriented thinking reasons in named packages of ideas, steps, data and logic: each package need not know the inside of others. Object-oriented programming (OOP) defines an object as a set of software offering methods, internal to the object, that external code can request be performed. Both approaches encourage code reuse, adding/changing functionality, refactoring, data modeling, data quality standards and security practices (preapproved libraries).

Languages are also classified by level of abstraction (closeness to the binary) and by data type enforcement: a language's ability to prevent operations on incompatible types. You cannot add "3" to a person's name; adding 3 to a date requires deciding whether it means days, months or years. Strong typing therefore protects the programmer from type errors. Add data protection / data hiding (preventing one unit from reading or altering another's private data) and code protection / logic hiding (preventing reading or altering another unit's source, intermediate or executable code).

Language generations frame the history. 1GL: machine language, opcodes, object code executed directly by the CPU - rare today, except malware reverse engineering and binary payload crafting. 2GL: assembly language, symbols abbreviating instructions, direct hardware interaction (kernels, device drivers) - also valuable to attackers. 3GL: HOLs using meaningful words (COBOL, FORTRAN, BASIC, Java, C). 4GL: report generators, application generators, drag-and-drop "codeless" platforms, scripting languages. 5GL: natural language interfaces, logic or constraint-based languages, sometimes leaning on AI (NLP, machine learning), largely obsolete by the 1990s. Exam trap: remember the mapping 1GL machine, 2GL assembly, 3GL HOL, 4GL generators/codeless, 5GL natural language, and that each generation introduces security and reliability controls absent from the prior one.

Two design-quality metrics shape how code is split into modules or objects: coupling measures the degree of dependency between modules, and cohesion measures how strongly the elements of one module serve a single responsibility. The design goal is low coupling (independent modules, changeable in isolation) and high cohesion (each module does one thing well). Code with high coupling and low cohesion is fragile: a change ripples everywhere, safe reuse becomes impossible and the attack surface grows. Encapsulation directly promotes low coupling and high cohesion.

7.4 Object-oriented concepts and distributed OO systems

OOP flips the perspective: the interest is in the objects to manipulate rather than the logic that manipulates them. An object is a block of statements offering methods to work on data; it encapsulates both the data and the processing instructions, and can be reused in any program that needs it (Java, Python, C++, C#, Ruby, Smalltalk). Four characteristics dominate. Encapsulation: a class defines only the data it is concerned with, and an instance cannot accidentally access other data - this is data hiding. Inheritance: define subclasses sharing some or all of the super class's characteristics; if security is well implemented in the high class, subclasses inherit it. Polymorphism: an object can "take many forms" based on use, so a change does not ripple into every application - but beware, secure methods can be lost through polymorphism, to assess carefully.

Polyinstantiation is the OO characteristic most useful to security. It creates a new version of an object under the same identifier/key, so different user processes hold their own local copy; it lets different versions of the same resource exist at different classification levels. It thereby prevents lower-level users or processes from knowing a higher level exists. This is precisely what prevents inference: inference is a user's ability to deduce more sensitive information by observing authorized information. Polyinstantiation counters inference attacks against databases by letting several versions coexist at distinct classifications.

Distributed OO systems split the application into logical components spread across machines, which communicate and call each other on demand, with code downloaded from remote machines transparently. Examples: CORBA, Java RMI, EJB (a Sun model providing a CORBA-like environment via APIs and relying on RMI), and DCOM. To standardize locating, initiating and sending requests to objects, the Object Management Group (OMG) created the Object Request Broker (ORB), the central piece of CORBA (Figure 8.15). The ORB sits between client and server, independent of processor or language; security-wise, it handles all requests and can enforce policies. The CORBA security service covers four policy types: access control, data protection, non-repudiation, auditing. Exam trap: associate ORB with CORBA/OMG, and remember polyinstantiation is the answer to the keyword "inference".

7.5 Who writes your source code? The trust spectrum

Asking "who writes your source code?" is the same as asking how you assure the security and integrity of your software supply chain. Providers fall on a decreasing trust spectrum. At the top, major hardware and systems vendors generally have robust, trustworthy processes ensuring product integrity and security. Next come applications software providers, sometimes large companies serving millions, whose secure updates and support add to trustworthiness. Third-party developers produce custom software or tailor a commercial product, but should be engaged only if there is agreement on how to provide and assess security. In-house developers work within a formalized quality assurance, configuration management and security assessment framework, offering as much control and accountability as the organization chooses to invest.

Subsequent layers become less and less secure. Open-source providers offer variable, sometimes nonexistent post-download support, and not always through verifiable means like signed downloads (also shareware or freeware). Citizen programmers - members of the organization who codify their knowledge into scripts or 4GL programs, often from examples found online and lightly modified - operate almost always beyond the reach of software quality, configuration management or security assessment processes, with little regard for security. At the very bottom, mobile code is the least inherently trustworthy form: the receiving system's owners have no visibility or influence over its development.

Mobile code (also called executable content, mobile agents, downloadable code, active capsules) moves the code itself, not just data, often without the user's explicit action or consent. Exam distinction: mobile agents migrate host to host at times and places of their own choosing, with high autonomy, hence hard to counter if malicious; applets are downloaded following a user action then executed start to finish on their machine (ActiveX, Java applets, in-browser scripts). Since the code will ultimately run locally, two controls limit risk: running the code in a restricted environment where it cannot do harm (sandbox), and using cryptographic authentication (certificates and signatures) to authenticate where the code comes from. The sandbox limits access to system resources (file system, CPU, network).

7.6 Buffer overflow and exploitable input errors

A buffer is a contiguous storage area used to transfer data from one device, program or process to another. A buffer overflow condition exists when that buffer receives more data than it was designed to hold: too much text in a dialog box, an over-long URL, an oversized network packet. The application then overflows the memory allocated to the buffer and writes the excess into system memory, which may be reserved for instruction processing. If the attack is done cleverly, the excess contains machine-language instructions: at the next execution step, the attacker's code runs (Figure 8.16). Often sloppy code lets a loop write beyond the buffer's declared 16 bytes; the vulnerability exists if the source can push more than 16 bytes without the software noticing, writing the 17th byte outside the buffer. The desired result is to put the attack instructions into memory and have them execute - this is arbitrary code execution, typically used to elevate privileges.

A buffer overflow is technically a form of malformed input. Safe software must do two things: accept input only if it passes a series of well-defined constraint checks (else reject it), and never misbehave, fail abnormally or allow arbitrary code execution when input does not meet all constraints. Malformed input attacks provide inconsistent data to induce a malfunction: a banking app may accept a maximum withdrawal of £10,000, but attempting to enter £11,000 must never crash it. Defensive programming translates the business logic about acceptable and harmful input into code that processes the good and safely blocks injections. Subtlety: a blocked URL expressed in ASCII rather than Unicode may slip past the firewall while the browser converts it without difficulty.

Controls against incomplete parameter checking go beyond testing each parameter in isolation: the receiving software must test the full set of values for consistency, validity and completeness (a false invoice attack may use a nonexistent but format-valid customer ID). Buffer overflows are prevented at several levels: enforce bounds checking (forbid access beyond the buffer), use a strong-typing language isolating code from data, and properly detect/intercept errors (even a divide-by-zero can open an exploit). Two injection attacks stem from the same flaw: SQL injection, where syntactic structures fool filters into seeing the query as a comment rather than an instruction, returning more information than intended; and cross-site scripting (XSS), where a site accepting user input (a blog) fails to detect that the input is active scripting later run on other users.

7.7 Covert channels and memory reuse

A covert channel (or covert path) is a communication channel between two or more processes that transfers information in violation of a security policy or requirement. It often uses transmission means not considered communications, making it undetectable or unblocked by routine security methods. It is created two ways: wittingly, by the cooperative, deliberate design of the two processes to create and manage the channel; or unwittingly, by a hostile process exploiting hitherto unrecognized information exposures of the target system. By facilitating the surreptitious passing of information, covert channels serve to exfiltrate sensitive data but also as a command-and-control mechanism in an advanced persistent threat (APT) attack.

Two types contrast. The covert storage channel (CSC) involves the direct or indirect use (read/write) of a storage location by one process and use of the same location by another: memory locations, shared disk sectors, cache, or unused bits in network-traffic headers. The CSC may violate policy directly (if the hostile process runs at a lower security level) or indirectly (a link in an exfiltration pipeline). The covert timing channel (CTC) alters the timing of a resource's behavior to pass information to an observing process, like modulating information onto a pulse train; example: stretching the response time to a handshake to just short of the timeout to signal. CTCs are often hard to detect. Every covert channel relies on a shared resource: identify them in design by spotting shared resources open to abuse, then decide which to mitigate (redesign, stricter access controls).

Memory or object reuse poses a related risk. Memory management allocates, de-allocates then reallocates sections to different processes (RAM, cache, disk). If residual information remains when a section is reassigned, the next process can read and reuse that data: this is a memory leak, a typical CSC example (most often unwitting). It applies to any resource where data can be stored: main memory, file storage, hardware buffers, and especially the paging/swap file, often left unprotected and rich in sensitive information. Data remanence controls limit or even eliminate this risk: from hardware/firmware up through applications, every element must ensure its memory resources' content is randomized, zeroed or otherwise overwritten before being allocated to another process. Exam trap: a memory leak and an unprotected page/swap file are CSC examples, not CTC.

7.8 Time-based attack vectors: TOCTOU, race conditions, backdoors

Attacks against distributed systems often rely on two complementary levers. Social engineering emotionally manipulates a victim (deception, intimidation, pulling rank, exploiting guilt or the desire to help) to obtain information or access and bypass controls; it paves the way for more sophisticated technical attacks. End-user training and awareness are the first and best line of defense, beyond email phishing alone.

Time of Check vs Time of Use (TOCTOU) exploits a change in control information between when security functions check a variable and when that variable is used. Example: an employee logged in that morning is fired, the account disabled, but since they did not log off, the session keeps its privileges - hence the importance of deprovisioning. In Figure 8.17, Process 1 validates credentials to open file A (unsecure) and Process 2 accesses the file; the attacker redirects Process 2 to a secure file (payroll) after authorization but before execution. Countermeasure: software locking (a lock on the file/resource) prevents file substitution during access validation.

A race condition exists when two tasks each depend on the other's completion for their input, and must run in the right order (Process 1 then Process 2). If an attacker disrupts that order, they manipulate the combined result: for example, forcing authorization to run before authentication would grant access without authenticating identity. The fix is to enforce atomic operations and not split critical tasks. The difference is subtle but crucial: in a race condition, the attacker controls the outcome by forcing two processes to run out of sequence; in a TOCTOU, the attacker inserts themselves between two executing processes to redirect the second. The between-the-lines attack is a different family: the attacker exploits tapped telecommunication lines (piggybacking on an active line) to inject false data - not to be confused with a backdoor, a race condition or a buffer overflow. Finally, trapdoor, backdoor and maintenance hook name a hidden means of transferring control left in the code, offering unintended entry that bypasses authentication.

8.1 Threats to databases and data warehouses

Databases and data warehouses expose a rich attack surface. The flagship threat is the aggregation / inference pair. Aggregation means combining nonsensitive data from separate sources to produce sensitive information: a user assembles two unclassified fragments and obtains a classified whole they are not entitled to, because the sensitivity of the combination exceeds that of the parts. Inference goes further: it is the ability to deduce more sensitive information than you should be allowed. Being able to aggregate often opens the door to inference.

The other threats: bypass attacks circumvent front-end controls (DBMS and query engine) by routes other than the interface or CLI; compromise of database views, when a user reaches restricted views or modifies one (a view limits what is seen, not the operations allowed); alternative but not equivalent access routes, since the layered model offers several paths to the same data (view, direct query, direct file access) not all equally protected; data contamination through malformed inputs at the field, record, transaction or file level.

Deadlocking (the 'deadly embrace') occurs when two concurrent processes each hold a lock on an object and wait for the other's lock; the system aborts one transaction (ideally the cheapest to roll back) to break the situation. Then come DoS (a query or table scan that saturates tables), improper modification (an integrity issue), interception of data in transit during remote access, query attacks (tools or malformed SQL to bypass the trusted front end and its views), direct physical/logical server access, TOCTOU (code changes the data between query approval and display) and web-based attacks (static or dynamic pages exposing sensitive data via 'show code'). Trap: aggregation and inference are the terms the exam expects here, do not confuse them with plain unauthorized access.

8.2 The database and data warehouse environment

A database is a repository of organized, valuable information. Historically, organizations managed files, which were hard to maintain and prone to errors and inconsistencies. Database architectures answered this, with the DBMS (Database Management System) at their heart: a suite of applications that manages databases and their environment. The heart of the DBMS is the database engine, the core application that performs the CRUD functions (create, read, update, delete) and makes data available for display or export while preserving confidentiality, integrity and availability.

The database itself is a large, structured collection of persistent, related data tables. From the OS perspective it is a set of file spaces managed by the DBMS, not meaningfully readable as a normal file by other applications. The full environment may include VMs, middleware between applications and the engine, utilities and, increasingly, a web front end. Each added component raises complexity and security requirements: you secure an architecture by securing each of its components.

As organizations multiplied databases, they consolidated data into data warehouses to give analytics, trending and reporting a richer context. A data lake is a large collection of data not yet put into the common format of a warehouse; a data farm is where predictive analytics generates data between known or observed points. The whole set of internet-interconnected sources is loosely called big data. Trap: data lake = raw data not commonly structured; data warehouse = integrated, structured data for analysis.

8.3 Hierarchical, network and graph models

A database model describes the relationships between data entities and provides the organizing framework. Every model must meet minimum requirements: transaction persistence (the post-transaction state is durable), fault tolerance and recovery via rollback (cleanly backing out incomplete or invalid transactions) and shadowing (reapplying transactions to a prior version, using transaction logging), sharing among multiple concurrent users without harming integrity, and security controls (confidentiality, integrity, availability, access controls, view definitions). Do not confuse: a database model describes the organization/structure/architecture the DBMS offers, while a data model describes the data types specific to an organization (a 'customer' data model lists name, address, etc.).

The hierarchical model is the oldest (1950s-60s). It stores data in records carrying field values, groups instances of the same record into a record type, and links them through parent-child relationships in a tree structure. Powerful and adaptable for organizing dissimilar data, but hard to extend when new business functions appear.

The network model (also called CODASYL, 1959, which led to COBOL) represents data as a network of records and sets joined by linked lists. Record types are the equivalent of tables in the relational model, and set types express the relationship between two record types. More performant than hierarchical for some functions, but less flexible than relational. Today it has two strong uses: high-performance/high-volume parallel storage (clouds, search engines) and graph databases. The graph model represents nodes (objects) and labeled arcs describing the nature of the connection; Neo4J is used in insider threat detection, anti-money-laundering and COVID-19 contact tracing. Trap: 'network' does not mean a computer network but a network of links between records.

8.4 The relational model, object-oriented and the ACID test

The relational model structures data in two-dimensional tables (or relations): columns represent the variables, rows hold data instances, organized using normal forms that let tables be linked together. It offers three elements: data structures (tables/relations), integrity rules on allowable values, and manipulation agents providing the relational mathematical basis. Vocabulary to master: each table is a set (an unordered collection); each row is a tuple (record) holding attributes (fields), one per column; one attribute is designated the primary key, others can also be keys. A tuple is found by matching values or via the primary index; filtering produces a subset; a join links two or more tables via specified attributes. Relational has become dominant in DBMSs.

The object-oriented (OO) model stores data as objects, collections of public and private elements together with the operations (methods) executable on them. Because the object carries its own operations, any call to data potentially has the full range of functions available, hence a strong security requirement. The OO model does not necessarily need a high-level language like SQL since the functions are contained within the objects, avoiding the language overhead. The natural evolution, the object-relational model, is a hybrid combining the advantages of relational and OO and offering a migration path.

Models are often evaluated via the ACID test: Atomicity (a transaction is all-or-nothing, indivisible), Consistency (the transaction honors integrity constraints and leaves the database consistent), Isolation (concurrent transactions stay invisible to each other until they complete) and Durability (committed effects are permanent). Central trap: Isolation = invisibility until completion, not to be confused with Atomicity (all-or-nothing), Consistency (integrity constraints) or Durability (permanence).

8.5 Interface languages and database connections

Interface languages (often called query languages) let users, administrators and applications request services from the DBMS. The connection must always go through authentication and authorization. SQL, created at IBM in the early 1970s for relational systems, remains the lingua franca of databases. It establishes three concepts: schemas (the database structure, including access controls), tables (columns and rows) and views (down-selections of rows/columns created dynamically per user, implementing security policies and access granularity such as separation of duties or data classification). SQL breaks into three sublanguages: DDL (Data Definition Language) to create databases, tables, views and keys, reserved for administrators; DML (Data Manipulation Language) to query, insert, delete and update data; DCL (Data Control Language) to establish and control access to data. Since DCL carries the security-control aspect, the security professional should pay attention to it.

Markup languages are not programming languages: they express how data should be formatted. HTML describes a page's layout. XML, the most recognized after HTML, provides data storage and transport over networks and interfaces web pages (front end) with databases (back end); it is an example of mobile code and is often used to define metadata. Embedded XML must be inspected and framed by trustworthy frameworks.

To connect applications to databases: ODBC (Open Database Connectivity, from Microsoft) is the dominant means of standardized access; it translates application commands into those of the target database system, allowing a change of DBMS with little modification, but because it operates as a system entity it is vulnerable (plaintext credentials, cleartext data, sometimes inadequate access verification, aggregation across sources). JDBC (Java Database Connectivity, from Sun) connects Java programs to databases, directly or via ODBC. OLE DB, based on COM (Component Object Model), links data across various DBMSs and runs as client or server middleware. ADO (ActiveX Data Objects, from Microsoft) is a high-level interface that simplifies OLE DB use (a front-end client or a middle-tier business object), criticized for its unrestricted system access, mitigated by sandboxing in recent browsers. Finally, the tiered approach (3-tier: presentation, business logic, data) strengthens security because the user does not touch the data directly but goes through the business logic layer; the risk is losing the database's security features in the translation by the middle layer. Trap: ODBC does not rely on HTTP, unlike REST APIs.

8.6 Internet access, analytics and knowledge discovery

Metadata is information that describes other information, literally 'data about the data'. It provides a systematic way to describe resources and improves search precision. It reveals unseen relationships between data, lets previously unrelated data be correlated and gives the keys to a data warehouse's critical data. Since the warehouse is generally at the highest classification level while its users are not, non-public data must be removed from the metadata: you abstract the correlations without exposing the underlying data. Warehouse data is exploited via OLAP, data mining or KDD.

OLAP (Online Analytical Processing) lets the analyst formulate queries then define further ones based on the results, roaming through the data before presenting information to management. Data mining runs queries against the warehouse to reveal hidden relationships, patterns, correlations and trends using mathematical and statistical techniques. Risks: privacy harm when mining individual data, and data contamination when collection/transformation/loading errors produce inaccurate relationships. Positive aspect: mining audit logs to spot abnormal events. Knowledge management efficiently manages an enterprise's information and resources to produce business intelligence, often relying on the data warehouse and now on AI.

KDD (Knowledge Discovery in Databases) is a mathematical, statistical and visualization method to identify valid, useful patterns and derive meaningful information, usually obtained through AI techniques rather than standard queries. Its approaches include the probabilistic model (graphs, uncertainty), the statistical approach (rule discovery, of which OLAP is an example), classification (grouping by similarity, removing redundancy) and deviation and trend analysis (filtering, e.g. an IDS). As an inference countermeasure, polyinstantiation creates multiple versions of a record at different classification levels, preventing the deduction of sensitive information. KDD security controls: protect the knowledge base as any database, routinely verify outputs match expected outcomes from inputs, route rule changes through change control, rerun queries if an output looks suspicious, fold risk into decisions and establish a baseline of expected performance. Trap: KDD = visualization and pattern identification for decisions; data mining = extraction of hidden relationships.

9.1 Web application environment and the OWASP Top 10

The web application environment is where an application runs on a server and exposes the interface through which users interact with the organization. Because it is accessible to the whole internet, it becomes a prime target: statistics show most attacks now hit the application layer (the web server itself, in-house scripts, e-commerce front-ends) rather than the underlying platforms. Once the application is compromised, attacking the OS and the rest of the architecture generally becomes possible. A site is easily captured by traversal tools that follow every link to make a local copy: the very transfer of mobile code that serves the legitimate browser also serves the attacker's technical reconnaissance.

Sites suffer from classic design mistakes: trying to reinvent (hand-code) access control and authentication, designing one's own cryptography, hard-coding credentials or sensitive data into pages or scripts, poorly managing access control, and above all coding absent or flawed input validation. Each page, each link, each GET or POST operation is a point of the threat surface an attacker can discover and exploit. The most frequent attacks are: DoS and DDoS, man-in-the-middle (MITM), SQL injection, cross-site scripting (XSS) and cross-site request forgery (CSRF).

Protection strategies emerge from painful lessons: a security sign-off process for web servers, OS hardening (removing default accounts and configurations, correct permissions, up-to-date patches), vulnerability scans before deployment, IDS/IPS deployment, application proxy firewalls, disabling unnecessary documentation and libraries, securing or removing admin interfaces, access limited to authorized hosts with strong (multifactor) authentication, no hard-coded credentials, account lockout, extended logging, and encryption of all authentication traffic.

The Open Web Application Security Project (OWASP) is the reference resource for secure web development. It provides many projects (Zed Attack Proxy, Web Security Testing Guide, Cheat Sheet Series, Security Knowledge Framework) but the security professional must above all know the OWASP Top 10 web application vulnerabilities and how to mitigate them. Exam trap: OWASP is not a tool, it is a project/community; and the Top 10 is a list of risk categories, not a ranking of products.

9.2 Web code defenses and secure coding standards

Because of the accessibility of web systems, input validation becomes the essential defense: every incoming datum (and output) must be validated. Application proxy firewalls help but must handle known exploits - buffer overflows, authentication issues, scripting, passing commands to the underlying platform (SQL to the database engine), encoding issues (Unicode) and URL encoding/translation. The golden rule: the biggest challenge arises when data passes from anything to anything else - validation must be adequate at that precise moment. To input validation is added output encoding, which neutralizes data before returning it to the browser (the core defense against XSS).

Session management deserves special attention because HTTP is a stateless protocol: the sense of attachment to the server is carried by other technologies (cookies, URL data) that must be protected and validated. If cookies are used, they must always be encrypted. Time validation is part of session management: sequential, calculable or predictable cookies, session numbers or URL data must be disallowed, always using random and unique indicators. As with any application environment, validate all input and output, fail secure (closed), keep the application as simple as possible, use pen testing and secure network design, and apply defense in depth (DiD). Never: cache secure pages, trust data from the client, or automatically trust data from other servers or partners.

Secure coding guidelines & standards encourage developers to follow a set of rules determined by the organization's needs, rather than coding by personal preference or familiarity. Standards exist per language (C, C++, Java, Perl) and come from groups such as the CERT division of the SEI and OWASP. Strong data typing aids safe execution: a type-safe (strongly typed) language inserts logic at compile time preventing the misuse of a data type - arrays staying in bounds, pointers always valid, the impossibility of placing code in a string and then executing it (which prevents injection). Java performs static type checking; in C/C++, memory access through pointers is one of the main sources of vulnerabilities, hence the value of controlling or restricting their use.

Two final practices. First, limit reuse to trusted libraries: reusing a snippet is tempting but risky because the programmer may misunderstand what the code does, or the code may not function correctly - teams must set firm limits on reuse and policies on approved libraries. Second, enforcing standards has two faces: administrative (instruct, motivate, engage the team) and technical (leverage IDE features, configuration management and change tracking systems, and audits of usage if needed). Exam trap: input validation and output encoding are the two fundamental web code defenses - distinguish them, one filters what comes in, the other neutralizes what goes out.

9.3 REST API security and authentication options

APIs (Application Programming Interfaces) are the connectors that let different components communicate - like a messenger carrying information between the applications of a system so it works seamlessly. IoT is the perfect example: when a fitness wristband sends your jogging time to a site, when you unlock a car from an app, when you change your thermostat's temperature from the office, an API works behind the scenes. These APIs must be managed and secured, otherwise wrong messages influenced by attackers may reach the applications. The unifying framework is data governance: a structured, controlled development of APIs that secures all data exchanges from the very beginning of the life cycle.

Websites and web apps come in two forms: stateful (both parties track a shared sequence, like negotiating an HTTPS session) and stateless (no synchronization required, like UDP). Representational State Transfer (REST) is not an architecture but an architectural style for building services on top of the web; it uses simple HTTP to enable interaction via simplified URLs. It is precisely because REST relies on simple HTTP that protecting REST services becomes tricky: it is doable, but it demands rigorous and consistent work across the enterprise.

REST recommendations: employ the same security mechanisms as any web application (if you filter XSS on the front end, do it for your APIs too, ideally with the same tools); do not reinvent your own security solution but use a peer-reviewed framework; do not rely on single key-based authentication (except for a free read-only public API); never transmit unencrypted static keys; and ideally use HMAC (hash-based message authentication code) with SHA-2 or SHA-3, avoiding SHA-1 and MD5 because of their known weaknesses.

Three authentication options for REST APIs. Basic authentication with TLS: the simplest to implement (included in most frameworks) but the least secure; never use it without TLS, otherwise the login/password pair is easily deduced. OAuth 1.0a: the most secure of the three, it uses a cryptographic signature (typically HMAC-SHA1) combining the token secret, a nonce and other info; its great advantage is that the token secret is never sent across the wire, making it the only one of the three usable without TLS (TLS still recommended depending on sensitivity). OAuth 2: the next evolution, it removes signatures - no more cryptographic algorithms to generate them - because all encryption is now handled by TLS, which becomes mandatory. Also consider: KMIP V1.1 and HSMs for key and certificate management, and the OWASP REST Security Cheat Sheet (which recommends session tokens to protect authentication from sniffers). Exam trap: OAuth 1.0a signs (usable without TLS); OAuth 2 no longer signs and requires TLS.

REST is not the only API family: SOAP (Simple Object Access Protocol) is an older, XML-based, strict and strongly typed protocol that carries messages in an XML envelope and includes WS-Security (message-level signing, encryption, tokens). SOAP is stateful and suited to critical transactions or formal contracts (WSDL); REST is lightweight, stateless, relies on HTTP verbs and JSON, and dominates web and mobile. Exam trap: SOAP carries its own message-level security (WS-Security) independent of transport, whereas REST relies on TLS to protect data in transit.

9.4 Malware taxonomy

Malware compromises a system's integrity, often by attaching to programs or executable files and delivering a payload that erases data, alters it, opens covert channels or exfiltrates information - this is the negative payload. Malware succeeds largely thanks to its social engineering component. At the heart of the taxonomy: the virus, a program written to copy and disperse itself without the user's cooperation; Fred Cohen's definition (1984) describes it as a program that modifies other programs to include a version of itself. Key exam point: a virus requires user action (double-clicking an attachment, launching a program) to infect. Virus types include: file infectors (infect program/object files; system infectors targeting the OS are a subcategory), boot sector infectors (replace the master boot record), macro viruses (via VBA in Word/Excel, infect data files like NORMAL.DOT), script viruses (standalone interpreted .vbs files, e.g. LoveLetter), multipartite (infect several object types or reproduce in several ways, e.g. Nimda), companion viruses (create a copy with another extension, e.g. .COM before a .EXE) and email viruses (exploit mail functions, e.g. Melissa).

The worm reproduces and spreads like a virus but differs fundamentally: it spreads WITHOUT user action, traversing networks of its own accord by exploiting known vulnerabilities. Needing no human involvement, it spreads far faster (worldwide in hours or even minutes). The first notable worm was the Morris Internet Worm of 1988. The trojan (Trojan horse) pretends to do something useful while performing an undocumented malicious action; it does not reproduce. The Remote Access Trojan (RAT) is installed remotely after deployment to give the attacker full control of the target host without alert; it is not viral (does not spread on its own) but can be dropped as a virus payload, and often makes the host a member of a botnet. DDoS zombies are compromised machines in the middle, unaware they are part of a distributed DoS attack.

The logic bomb stays dormant until a specific condition (a date, the state of a database) then activates its negative payload; hard to implant after the fact, it is coded into an application under development or maintenance, involves neither reproduction nor social engineering, and a classic example is the salami scam (siphoning fractions of a cent across many transactions). Spyware and adware sit at the legitimate borderline: initially marketing tools tracking browsing habits, grown intrusive, they are often called PUP/PUA (potentially unwanted programs/applications) to focus on the lack of consent rather than alleged harm. The hoax is a fake virus alert pushing you to forward it to all your contacts (a kind of self-perpetuating spam). Pranks and Easter eggs (hidden functions) are jokes without malicious intent but consume resources and complicate integrity.

The botnet is a network of automated bots acting together toward an often malicious goal; its distributed nature and techniques like fast-flux (rapid rotation of domain names and IP addresses) make it hard to detect and neutralize; bots are usually dropped by trojans. Finally, ransomware encrypts the victim's files and sells the decryption key (often in Bitcoin); a variant, living off the land (a non-malware attack), uses no malware but native system capabilities (such as file system encryption tools) for the same result. Exam trap: virus = user action required and modifies other programs; worm = autonomous spread over the network, no user action.

9.5 Software-Defined Security (SDS) and Zero Trust

Software-Defined Security (SDS) is a major paradigm shift in how we think about and secure information systems architectures. In simple terms, it is the difference between the client-server model resting on an on-premises server and a fully cloud-based model, with no on-site architecture beyond the internet point of presence and local access points. The client-server model extended to the internet required perimeter thinking, layered defenses (DiD), and it trusted entities moving laterally within a layer. Around 2018, the market cried that defense in depth is dead to signal the need for SDS against sophisticated attackers. The nuance, quickly added: it is not the layers that are the problem, but that traditional DiD has no effective control over lateral movement within a layer, nor any real defense against the insider threat.

For a globe-spanning enterprise (50 sites, 10,000 users, cloud assets, microsegmentation requiring hundreds of firewalls, routers, NIPS/NIDS driven by SIEMs and SOAR), shifting to SDS brings several advantages: it centralizes the control plane for all network segments, reducing overhead while enabling rapid enterprise-wide changes; it favors virtualized security appliances, reducing hardware and vendor dependence; it makes security policies on-demand, agile and adaptable; it can eliminate older converged protocols like MPLS via virtual overlays; and it shifts threat intelligence from reactive to predictive by combining machine and human learning. Properly implemented, SDS also offers a bridgehead to holistic all-source risk management.

It must be stressed that traditional component-level elements have not disappeared: access to Layer 2 internet services and, above all, the fundamental problem of identity management and access control remain. Every user, human or nonhuman, and every device, software entity or process must be subject to the full suite of IAM controls - this is the rock on which SDS must stand before becoming holistic. Several ideas are now established at the core of SDS: identity management is absolutely vital; entities (not just users) must be the level at which identity is defined and tracked; defense must become proactive; systems must be agile; access management must push down to the lowest-level asset; and the Zero Trust Architecture (ZTA) both enables SDS and is required by it. ZTA uses microsegmentation and IAM functions; it is not a mere relabeling of DiD - for instance, highly localized segments are defined per IoT type, with trusted agents acting as brokers between an IoT segment and the rest (warehouse sensors have no reason to access HR or finance systems).

SDS and assessment raise two fundamental, intertwined questions: (1) are the systems the organization depends on operating as required to meet both compliance needs AND the reality of today's threat environment? (2) are the SDS and other security processes we have put in place working correctly? The first belongs to Domain 6; the second is a special case of the third-party security assessment problem - placing all your security capabilities into the virtual hands of an SDS installation requires considerable trust, and that system must be treated as a high-value, mission-critical asset. The choice of an SDS vendor, in-house or as a managed service, must factor in assessment and compliance needs from the start. Exam trap: SDS and ZTA do not mean the perimeter or layers are dead; they fix DiD's blind spot - lateral movement - by putting identity management at the center.