Softwares and Software Security: formula sheet

Key formulas

Basic classification by purpose

Software = System software + Application software

Utilities, drivers, firmware and translators sit under system software. Programming tools are usually treated as system software.

Classification by licence

Open source (source code open) vs Proprietary (source code closed)

Open source is not the same as free of cost. The licence terms still bind you.

System vs application test

Manages the machine = system software; serves a user task = application software

Use this one-line test for any example in a question.

Application software by build

Packaged (ready-made) vs Customised or bespoke (built for one client)

A useful extra point in a differentiate answer.

Phases of SDLC (in order)

Planning → Requirements → Design → Development → Testing → Deployment → Maintenance

Some books merge or rename phases. Keep the order and say which version you follow.

Waterfall model

Linear: finish one phase, then start the next

Best for stable requirements. Weak when change is likely.

Agile model

Short iterations (sprints) + frequent feedback = working software in small increments

Best for changing requirements and close customer involvement.

Spiral model

Each loop = plan + risk analysis + build + evaluate

Risk analysis in every loop is the key feature.

DevOps

Development + Operations + automation (CI/CD)

Aims at fast, frequent and reliable releases.

Secure SDLC

Security activity in every phase, not only at testing

Shift security left: address it early in the cycle.

Licence versus ownership

Licence = right to use on terms; copyright stays with the owner

Buying a licence does not transfer ownership of the software or its code.

Copyright in software

Computer programme = literary work; protection arises automatically on creation

Registration is not a condition of protection. It is useful as evidence.

Patent position in India

Computer programme per se: not patentable; technical effect or contribution: may qualify

Do not say software is never patentable.

Freeware vs shareware

Freeware = free, no payment due; Shareware = free trial, payment to continue or unlock

Neither gives source code or modification rights by default.

Open source vs freeware

Open source = source code available plus rights to modify and share; Freeware = no price only

Free of cost does not mean open source.

Risk relationship

Risk = Threat × Vulnerability × Impact

A conceptual relationship, not a numeric calculation. If any one is absent, risk is low.

Vulnerability vs threat vs exploit

Vulnerability = weakness; Threat = possible danger; Exploit = method that uses the weakness

Define all three separately. Examiners often test the difference.

Malware spread rule

Virus needs a host and user action; Worm self-spreads; Trojan disguises and does not self-replicate

Use this one-line contrast in any 'differentiate' question.

SQL injection defence

Parameterised query + input validation + least privilege

Parameterised queries are the primary defence; the others support it.

Zero-day

Unknown to vendor + no patch + exploited = zero-day attack

Once the vendor issues a patch, it is no longer a zero-day, though unpatched systems stay exposed.

Control types

Preventive + Detective + Corrective

Classify every control you name into one of these three groups. It shows structure in your answer.

Least privilege

User access = only what the job needs, nothing more

Reduces damage from errors, insider misuse and stolen credentials.

Confidentiality, Integrity, Availability

CIA triad = Confidentiality + Integrity + Availability

Link each control to the goal it protects. Encryption mainly protects confidentiality; backups protect availability.

Vulnerability assessment vs penetration test

VA = find and list weaknesses; PT = exploit them to prove impact

VA is broad and usually automated. PT is deeper, targeted, manual and needs written authorisation.

Patch cycle

Identify → Assess risk → Test → Deploy → Verify → Record

Use this order when asked how to run patch management.

ISO/IEC 27001 core idea

ISMS = scope + risk assessment + risk treatment + controls + monitoring + continual improvement

A management system standard. Certification is voluntary and given by an independent certification body.

Three security goals (CIA)

Confidentiality + Integrity + Availability

Every control and every breach in a case can be mapped to one or more of these.

Section 43A test

Body corporate + sensitive personal data + negligence in reasonable security practices + wrongful loss or gain = compensation

All elements must be present. Compensation is claimed through the adjudication process under the Act.

Section 43 (civil liability)

Act without permission of owner (access, virus, damage, disruption) = compensation

Civil remedy. If done dishonestly or fraudulently, Section 66 applies as an offence.

Section 72A

Service provider or any person + lawful contract + disclosure of personal information + intent to cause or knowing likelihood of wrongful loss or gain = punishment

Applies to disclosure in breach of a lawful contract, which is different from negligence under Section 43A.

OWASP Top 10 status

OWASP Top 10 = awareness list, voluntary, revised periodically

Not a statute. Do not say it is mandatory.

Quick revision

• System software runs and manages the hardware; application software performs user tasks.
• SDLC is a structured sequence of stages from planning to maintenance; security should be built into every stage.
• Fixing a flaw late in the life cycle is usually costlier than fixing it early.
• Software is generally protected as intellectual property, and a licence sets the terms of use.
• Using software beyond the licence terms can create legal liability for the company.
• A vulnerability is a weakness; a threat is something that can exploit it.
• Threats include malware, phishing, injection attacks and insider misuse.
• Controls can be preventive, detective or corrective; learn one example of each.
• Good practices include patching, access control, testing, secure coding and regular audits.
• Standards give a benchmark for security management; laws make certain duties mandatory.
• In a case answer, always link the facts to a specific control or legal duty.
• Always end with a clear conclusion and a practical recommendation.

Common mistakes

• Treating utility software as application software. Fix: Ask whether it maintains or protects the system. If yes, it is utility software under system software.
• Saying open source always means free of cost. Fix: Say that source code is available and use is governed by a licence. Some open source products are sold with support.
• Listing the SDLC phases in the wrong order, such as testing before development. Fix: Remember the story: plan, find needs, design, build, test, release, maintain.
• Saying agile has no planning or documentation. Fix: Say agile plans in short cycles and values working software and feedback. It is disciplined, not unplanned.
• Treating freeware and open source as the same thing Fix: Say freeware means no price only, while open source means source code access plus rights to modify and share under stated conditions.
• Saying shareware is free software Fix: Write that shareware is a trial. Payment is needed to continue after the period or to unlock full features.
• Using virus, worm and trojan as if they mean the same thing. Fix: Anchor on spread: virus needs a host file, worm spreads alone, trojan disguises itself and does not self-replicate.
• Saying a zero-day is a brand-new virus. Fix: A zero-day is a flaw unknown to the vendor with no patch available. It is about the vulnerability, not the type of malware.
• Treating vulnerability assessment and penetration testing as the same thing. Fix: State that assessment finds and lists weaknesses, while penetration testing exploits them with authorisation to show real impact.
• Saying patching is optional or only needed after an attack. Fix: Explain that patches close known flaws and delay lets attackers use them. Describe a regular, risk-ranked cycle.

Exam tips

• Always give named examples. A bare definition rarely earns full marks in a descriptive answer.
• For differentiate questions, write in point-wise pairs and cover at least four distinct points.
• Name the basis of classification before listing types. It shows structure.
• In case-based questions, classify the software first, then state the legal or security consequence.
• Spend your last line on a practical control: patching, licence audit, vetting of open source.
• Learn the seven phases in order and write one purpose line for each.
• For comparison questions, give at least five points in a clear list and end with suitability.
• In case questions, quote the facts that decide the model before naming it.