Domain 8. Supply Chain and Software Acquisition

  • Key Elements:
    • Products
    • Processes
    • People
  • Conventionally, there are 4 levels in the supply chain.

Acquisition Lifecycle

  • Planning:
    • Initial risk assessment and acquisition plan
    • Acquisition plan:
      • Requirements
      • Evaluation criteria: organisation, peopple, process, technology
  • Contracting:
    • Issuance of advertisements to suppliers,
    • Evaluation
    • Contract
    • Negotiation
    • Selection
    • Contract award
  • Development & testing:
    • Implement reliable, resilient and recoverable code
    • Attestation of security controls
  • Acceptance:
    • Define acceptance criteria
    • Verification and validation
      • 3rd party testing
      • Purchase order
      • Acquirer acceptance
      • Contract closure
  • Delivery:
    • Establish code escrow agreements
    • Attest compliance with regulations
    • Secure transfer
      • Secure delivery channel
      • Secure delivery process
  • Deployment:
    • Install/configure with least privilege and secure defaults
    • Post-validation
  • Operations & Monitoring:
    • Enforcement of contract work schedule
    • Post deployment support
    • Change management procedure
    • Integrity check
    • Patch management
    • Termination access controls
    • Checking custom code extensions
    • Continuous monitoring
    • Incident response
  • Retirement:
    • Handle information disclosure risks
    • Decommission
    • Termination access control
    • Disposal of data

Software Acquisition Models and Benefits

  • Direct purchase
  • Original Equipment Manufacturer (OEM) licensing
  • Partnering
  • outsourcing:
    • Subcontracting to 3rd party (cost-effective)
    • Offshoring: 3rd party is from overseas, primarily considered by a company
    • Problems:
      • Software provenance: responsibility shifted from one supplier to another eventually lost control
  • managed Services:
    • SLA is the primary instrument managed services are procured, delivered and enforced
  • Benefits:
    • Cost saving
    • Increased operational efficiency
    • Access to skilled staff
    • Objectivity and neutrality
    • Forced adoption of common standards

Managed Services

  • Aim of supply chain risk management: to ensure that the customer gets what they contracted for.
  • Managed services require continuous assurance of a persistent set of behavioral requirements.
    • Involves continuous customer-supplier interaction.
  • Requirement & Specification should cover:
    • Functions that must be performed by the supplier.
    • Criteria that will be used to evaluate these functions.
    • Changes to the contract are monitored through a formal change control process.

Service Level Agreements

  • SLA sets the requisite level of performance of a given contractual service between a customer and supplier.
    • Once entered, SLA becomes a legal binding document.
  • Two rules for SLA:
    • SLA clearly describes all functions in detail.
    • SLA provides PKI to indicate the functions meet agreed level.
  • Contracts should:
    • Express the expected level of performance.
    • Define externally observable behaviours.
    • Specify a process and criteria for evaluating the behaviours in the deliverable.
  • Changes may occure, the acquirer is responsible for ongoing maintenance of changes to the contracts.

Software Supply Chain Risk Management (SCRM)

  • Need to manage risks from:
    • Supplier
    • Supplier’s SDLC
    • Delivery process
  • Risk can come from:
    • Technical
    • Process
    • Resoucing
  • Process:
    • Identify and analyse software assurance risks
    • Validation and verification of contractual and technical controls prior to acquisition
    • Continuous assessment after acquisition until decommissioning
  • Bare minimum required in supply chain controls
    • Least privilege
    • Separation of duties: access to code/data restricted
    • Location agnostic protection (persistent protection): effective protection irrespective to the location of the software
    • Code inspection: present in SDLC
    • Tamper resistance and evidence: code/data protected with technical controls, restorable
    • Chain of custody: transfer of product from one supplier to another is controlled, authorised, transparent and verifiable
  • Responsibilities:
    • Shared responsibility for security between suppliers and acquirers
    • Ownership and liability of security breach is on the acquirer’s end
      • SLA must enforce contractual/technical controls

Supply Chain Software Goals

  • Conformance: ensures plan and follows a systematic approach to conform to the requirements.
  • Trustworthiness: ensure no vulnerabilities, software functions reliably assuring trust.
  • Authenticity: ensure no counterfeit or piracy.

Threats to Supply Chain Software

  • Product/Data Threats:
    • Tampering of the code to circumvent existing security controls.
    • Unauthorised disclosure, alteration, corruption, and/or deletion/destruction of data.
    • Diversion and/or re-routing of data causing disruptions and delays.
    • Code sabotage by intentionally implanting vulnerabilities and malicious logic.
    • Counterfeiting by substitution of legitimate products and/or data with similar but bogus ones.
    • Piracy and theft of intellectual property rights by reverse engineering executable code.
  • Processes/Flow Threats:
    • Bypass of legitimate flows and surreptitious diversion of legitimate channels to pirated ones.
    • Insecure code transfer that does not maintain chain of custody.
    • Violation of export control requirements.
    • Improper configuration of software allowing undocumented modifications and operational misuse.
  • People Threats:
    • Undetected placement of a malicious threat agent inside the company, i.e insider threat/pseudo-insider threat.
    • Social engineering insiders to commit fraud or perjury (i.e., subornation)
    • Foreign Ownership and Control or Influence (FOCI).

Supply Chain Risk Management Lifecycle

  • Planning
    • Perform an initial risk assessment to determine assurance requirements (protection needs elicitation)
    • Develop acquisition strategy and formulate plan with evaluation criteria
  • Contracting
    • Include SCRM as part of the acquisition advertisement (RFP, RFQ, etc.)
    • Develop contractual and technical controls requirements
    • Perform Supplier Risk Assessment (Supplier Sourcing)
    • Evaluate Supplier Responses
    • Establish Intellectual Properties (IP) ownership and responsibilities
    • Negotiate and award contract
  • Development & Testing
    • Evaluate conformance to assurance requirements
    • Conduct code reviews
    • Ensure security of code repositories
    • Ensure security of built tools and environment
    • Conduct security testing
  • Acceptance
    • Validate anti-tampering resistance and controls
    • Verify authenticity (code signing) & anticounterfeiting controls
    • Verify supplier claims
  • Delivery
    • Maintain Chain of Custody
    • Secure transfer
    • Enforce code escrows (if required)
    • Comply with export control & foreign trade data regulations
  • Deployment
    • Configure the software securely
    • Implement perimeter (network) defense controls
    • Validate System-of-Systems (SoS) security
  • Operations & Monitoring
    • Check runtime integrity assurance controls
    • Patch & Upgrade
    • Implement termination access controls
    • Check custom code extensions
    • Continuously monitor software/supplier
    • Manage security incidents
  • Retirement
    • Decommission (delete) or replace software
    • Dispose data to avoid risk of data remanence

Supplier Risk Assessment and Management

  • Supplier Risk Assessment:
    • An information-gathering function that focuses on understanding the consequences of all feasible risks.
    • Identify specific threats to the organization’s supply chain.
      • Determine the likelihood and impact of risks.
    • Identify and maintain an appropriate set of risk controls within the overall supply chain.
      • Ensure up-to-date knowledge about the supply chain’s overall threat situation.
  • Risk assessment framework:
    • To factor the identified risks and their mitigations into a “who, what, when” structure.
    • To identify the required inter-relationship.
  • Risk assessment for code reuse:
    • Aim:
      • Develop a secure library of reusable components.
      • Leveraging production and quality.
    • Threats can be introduced by re-using codes.
  • Two primary relationships:
    • Workfor-hire (subcontracting or staff augmentation)
    • Licensing relationships
  • Acquirers can:
    • Subcontracting work-for-hire:
      • Subcontract the development from other suppliers.
      • Acquirer owns the software.
    • Staff augmentation work-for-hire:
      • Work collaboratively with staff from other suppliers augmenting their own.
    • Arm’s length licensing:
      • License software from another supplier or obtain the software from open source.
  • General Accounting Office (GAO) threat categories:
    • Installation of malicious logic in hardware or software
    • Installation of counterfeit hardware or software
    • Failure or disruption in the production or distribution of a critical product or service
    • Reliance on a malicious or unqualified service provider for the performance of a technical service
    • Installation of unintentional vulnerabilities in software or hardware
  • Compliance: a condition or state in which the elements of the system satisfy a wide range of legal and regulatory requirements.
  • Challenges:
    • Developing objective and auditable evidence
    • Reporting to the appropriate legal and regulatory entities.

Supplier Prequalification

  • Aim: to ensure ICT product integrity and reliability.
  • Suppliers have to prove that they are capable of developing and integrating a secure product.
    • Including the ability to ensure that the subcontractors a prime contractor employs are trustworthy.
    • Define in advance what actions a supplier is not permitted to perform.

Assuring a Black Box: Commercially-Off-The-Shelf (COTS)

  • COTS is considered a black-box (hard to ensure the integrity and security).
  • Agreement is needed between the customer and supplier to certify both the trustworthiness and the capability.
  • Pre-qualification requires the customer to objectively understand the precise form of each supplier’s development process.

ISO 15408: The Common Criteria

  • By National Information Assurance Program (NIAP):
    • A type of third-party registry system, a.k.a Common Criteria
    • Build trust and assurance around the construction of customised program protection profiles for each target of evaluation (TOE) based on the security functional requirements specified in the standard.
      • characterized by Target of Evaluation and Security Targets
  • A financially justifiable and generally accepted certification should accomplish two aims:
    • Acquisition community should have objective and independent assurance that a supplier is trustworthy
    • Suppliers should be able to gauge their exact level of capability and improvment plan
  • Benefits:
    • Reduce uncertainties in the acquisition process
    • Provide an objective basis for business cost-effectiveness balancing
    • Independence between process capability and quality of product gives the best means of selecting risk controls

Supplier Sourcing

  • Perform a risk assessment for all potential suppliers prior to any engagement.
    • Risk-versus-return ranking: Higher scores are given to projects that meet or exceed expectations.
    • Important security consideration: determine the degree of FOCI.
  • Key Notes:
    • Specify which tasks and subcontractors can/cannot do.
    • All outsourcing decisions are guided by criteria in the contract.
    • Contractual integrity control is the most important criteria.
  • Trade-off:
    • Strategic improvements vs. maintenance of current operations
    • High vs. low risk: management must always balance the amount of risk they can afford against the ability to manage it.
    • Impact of one supplier on another
    • Opportunity costs

Supplier Evaluation (Pre-Qualification Assessment)

  • Organization:
    • Financial history.
    • Conflicts of interests and FOCI.
    • Compliance with security policies, regulatory and privacy requirements.
    • SLAs
      • Requirements-based
      • Data Classification to determine MTD and RTO
        • e.g Severity 1 incidents will warrant a 1-4 hour workaround
      • SLAs have a direct bearing on the Total Cost of Ownership (TCO)
      • Define KPIs:
        • Performance: Reliability in the functionality of the software
        • Disaster Recovery and Business Continuity: Speed of recovery of the software to a working state
        • Issues Management: number of issues (security) addressed/ deferred for future releases.
        • Incident Response: Promptness in responding to security incidents.
          • This is dependent on risk factors such as discoverability, reproducibility, elevated privileges, numbers of users affected, and damage potential.
        • Vulnerability Management (Patch and Release Cycle): Frequency of patches released and applied.
    • Past performance in supporting other customers.
  • Processes:
    • Security development lifecycle.
    • Security track record (vulnerability/patch management).
      • Collect input on vulnerabilities
        • e.g OWASP Top 10, NVDB, OSVDB, bug tracking lists, researchers and customers
      • Analyze the applicability of the vulnerabilities
      • Articulate the discovered vulnerabilities using common terminologies with references to relevant specifications
        • e.g., CWE, CVSS
      • Provide remediation within acceptable timeframes to fix the vulnerabilities
      • Provide calling rosters (points of contacts) and escalation plans to promptly address the vulnerabilities.
      • Show supplier’s responsiveness to vulnerabilities.
        • Can be contracted in SLA to enforce this.
  • People:
    • Security knowledge
    • Experience
    • Training

Response Evaluation

  • Request For Proposal (RFP), Request For Information (RFI), Request For Quote (RFQ)
  • Acquirer prepares work statement:
    • Describe Security Requirements and required evidence
    • Ensure security requirements are stated with measurement criteria in the RFP in addition to the functional requirements.
    • The time to respond to an RFPs must be specified; provisions for late offers may be stated.
    • Define evaluation criteria and process in the RFP
      • An understanding of the requirements (both functional and assurance)
      • A solution concept
      • Experiences of personnel
      • Valid references from past performance
      • Resources, cost, and schedule considerations
      • IP ownership and responsibilities

Contractual Controls

  • Contracts: legal agreements to perform a specified action or deliver a specified product.
    • Illustrate specific issue resolution process.
    • Contracts are two-sided
    • Conditions for stipulating and ensuring contractual integrity have to be built into the process.
  • Contractual Controls:
    • Applicable regulations and standards
    • Describe SDLC
    • Personnel qualifications and training.
    • Secure coding and configuration requirements
      • e.g., input validation, encoding, secure libraries and frameworks, safe application programming interfaces (APIs), authentication and access checks, session management, error handling, logging and auditing, interconnectivity, encryption, hashing, load balancing, replication, secure configuration, log management
    • Requirements to assure integrity of the
      • Development (e.g., code repositories, access control, version control, etc.)
      • Distribution (e.g., chain of custody, secure transfer of code and storage, etc.)
      • Environments
    • Right to conduct security code reviews:
      • Timeframe
      • Scope
      • Methodology
    • Testing terms:
      • Self-testing
      • 3rd party testing
    • Ownership and responsibilities w.r.t IP
    • Acceptance criteria
    • CNA process and documentation
    • Commitment to fixing/patching.
    • Supplier’s vulnerability management (patch and release cycle)
    • Malicious code warranties
    • Reliability guarantees
    • Certification of originality
    • Disclaimers provide software companies legal protection from liability claims or lawsuits that are unforeseen.
      • Disclaimers protect the software publisher by informing the purchaser that the software is sold “AS IS”
      • Transfer the risks from the publisher to the acquirer
      • The publisher will not be held legally accountable
      • One-sided notification of terms

Vendor Technical Integrity Controls for Third-Party Suppliers

  • Purpose:
    • Ensure all contractual requirements are passed to subcontractors.
    • Ensure all subcontractors within the supply chain are properly validated.
    • Ensure the correctness of the technical process of the subcontractors.
    • Ensure the completeness, consistency, and correctness of a formal set of components that comprise a given product.
    • Ensure that the organization knows the state of those components at all times.
  • Control types: tests and audits.
    • Aim: to coordinate contract security testing activities between the various interfaces.
    • Technical security controls: ensure joint security assurance in accordance with contractual specifications.
    • Security assurance tests: ensure sufficient verification and validation to support the fulfillment of requirements.
  • Consistent and reliable execution of technical controls is the only way to ensure reliable management.
  • Technical baseline: used to identify, define, and assure the integrity of a software.
  • Technical Controls: to ensure all participants in the supply chain follow proper practices in producing the technical work.
  • General assurance activities (all based on product requirements and supported by IEEE):
    • Unit testing: takes place during development
    • Integration testing: part of joint security testing during the software integration process
    • Qualification testing: takes place once major deliverables pass through acceptance checkpoints

Intellectual Property (IP) Ownership and Responsibilities

  • World Intellection Property Organization (WIPO) defines IP as the creations of the mind
  • Two types of IP (software is not patentable, but algorithms and methods are):
    • Industrial Protection
    • Copyright
  • Software IP (IP can represent business value):
    • Processes
    • Algorithms
    • Coding

Industrial Property

  • Innovative:
    • Patent (Inventions): a form of IP protection that is extended to novel inventions. (strongest format, usually 20 years)
      • A patent is not a secret
      • Protection is granted for a period of time
      • Practical use
      • Novel
      • Demonstrate an inventive step
      • Compliant with the law
    • Trade secret: any confidential business information that provides a company with a competitive advantage.
      • It must not be generally known.
      • It must have commercial value.
      • It must be protected by the holder of the information through confidentiality agreements.
      • Iusses of innocent discovery: the secret can be indenpendently discoverer by another party.
  • Fair competition:
    • Trademark: a form of IP protection on image, phrase, name, or some other distinct branding.
      • Can be renewed indefinitely
      • Trademark enjoys no protection from disclosure
      • Need to remain as a trade secret before becoming public
      • Trademarks can be either common law–based or registered
      • Using Madrid System, i.e The International Trademark System
  • A form of IP protection on specific works, giving the “creator” the ability to determine usage and conditions.
    • All software are copyright protected
    • Granting the creator with the exclusive rights to use, authorise or prohibit
    • Can sell the rights as royalties
    • Has expiration, defined by each country (usually 50 years)
  • Two relevant federal regulations
    • Computer Softare Rental Amendments Act 1990: forbids rental, lease or lending of copyrighted software without authorisation.
    • Copyright Law Title 17 of US Code: creation or distribution of copies of software without authorisation is illegal.
      • Exception given to backup copies for archival purpose.
  • Notes:
    • Peer-to-peer-based torrents sharing violates copyright.
    • Develop software with EULA with “I accept” (deterrent control).
    • Governed internationally through the Berne Convention.
    • Source code can be registered to protect copyright.

Warranty

  • A promise that a product will perform as expected.

Licensing (Usage and Redistribution Terms)

  • A legal instrument that governs the use and/or redistribution.
  • Licensing is a partnership between the owner (licensor) and the authorised user (licensee).
    • Usually in exchange for an agreed payment.
  • Two categories:
    • Closed source
    • Open source
  • Licensing types:
    • Two forms: User-based and Fixed-Term Licenses
    • Number: users, systems, unlimited
    • Time: fixed, unrestricted
    • Functionality: full, shareware
    • Territory: global, regional
    • Source Code
      • Closed:
        • Supplier reserves some or all of the licensing rights.
        • Ownership belongs to the publisher.
        • Original Equipment Manufacturer (OEM): licensed as a bundle with the hardware.
        • Off-The-Shelf: source code is not available to the acquirer.
          • Government off-the-shelf (GOTS): developed within a government agency by their staff.
          • Commercial off-the-shelf (COTS): ready-made and available for sale as-is.
          • Modifiable off-the-shelf (MOTS): a COTS product whose source code is modifiable.
          • Military off-the-shelf software: when used by military
        • Advantage:
          • Mass production reduces its overall cost to the acquirer
        • Disadvantage:
          • Manufacturer owns the software
      • Open:
        • Source code is available under a copyright license.
        • Permissive: minimal requirements on redistribution gives anyone a free reign to modify and source code.
          • e.g BSD, MIT
          • Copyright
        • Disadvantage:
          • Attacker can examine the code for exploits.
        • Free open source license: code can be inspected, modified and redistributed without any cost.
        • Freeware: copyrighted software that is free to use.
        • Copyleft licenses: reciprocity or share-like requirements
          • e.g GNU General Public License (GPL)
        • Need to let acquirer know if there is any open source used.

Code Escrow

  • An agreement that a copy of the source code be given to a neutral 3rd party ( i.e escrow agent), and that access to this source code becomes possible under specific circumstances, such as the business failure or termination of the supplier.

Software Development and Testing

  • Purpose of Validation and Verification (V&V):
    • Confirm that software reflect their specified requirements.
    • V&V serves to warrant the quality.
    • V&V determines if identified risks have been addressed properly.
    • V&V process needs to be documented, defined early and updated over time.
  • Where and when to apply V&V is a management decision based on evidence and supported by facts.
  • An evaluation process can only be as good as the degree of freedom granted by the organisation.

Code Testing

  • Purpose:
    • To ensure that the code is implemented properly and complies with all relevant requirements.
    • To make sure that the eventual realisation of the system embodies a trustworthy set of components.
  • For every code module, need to define:
    • A set of tests
    • Test cases
    • Test procedures
    • Regression strategy
  • Testing process need to be examined by
    • Appropriateness of test methods and standards
    • Conformance to expected results
    • Feasibility of the proposed testing
    • Preparation and maintenance of the testbed
  • Developer needs to evaluate the design, code, tests, test results and documentation using
    • Traceability
    • External and internal consistency
    • Appropriateness of the methodology and standards employed
    • Feasibility as the criteria for evaluation
  • Key Notes:
    • A set of criteria for confirming compliance are developed to test for compliance.
    • Criteria to judge the successful execution of the test have to be made explicit.
    • Testing results have to be documented for all stakeholders.
    • Ensure common coding errors are mitigated.
    • Check for unexpected functions.
    • The developer must audit the testing process itself in order to confirm that it was performed correctly.
    • The fact that software is procured via a supply chain does not eliminate the need to understand and verify the necessary testing regimens employed as part of the development process. These aspects are best handled via process validation vice product testing.
  • The success of the code-testing is judged by the degree of test coverage:
    • Code performance requirements
    • Conformance to expected results
    • Feasibility of operation and maintenance
    • Readiness for integration

Assurance Requirement Conformance Validation

  • Mandate suppliers to identify/describe the evidence of controls.
  • Demonstrate conformance to the assurance case stated in the work statement.
  • Conformance to stated security requirements, need to be verified with testing measures.
  • Demonstrable evidence that verifies the existence and effectiveness of security controls.
  • Supplier should be able to provide evidence to back up their assurance claims.

Software Requirements Testing and Validation

  • Purpose:
    • To confirm that all forms of the product moving within the supply chain comply with contractual requirements.
    • To reconcile the requirements set with the eventual product.
  • Both product and process need to comply.

Software Requirements Testing and Validation for Subcontractors

  • All contractual requirements need to be passed down to the subcontractors.
  • Acquirer is responsible for ensuring subcontractor management terms are captured in the contract.
  • Supplier is responsible for ensuring contract conditions are understood by the subcontractors and conduct V&V.
  • Subcontractors need to ensure all aspects comply with the contract.

Code Review

  • Peer-review: identify the presence of threats and threat agents.
  • Malicious code and logic: embedded backdoors, logic bombs, Trojan horses
  • Types: manual or automated
  • Recommended strategies:
    • Review on changed/modified code
    • Review on exercised code paths
    • Partner with the development team members of the supplier
    • Document vulnerabilities in an issue tracking database

Code Repository Security

  • Enforce least privilege and accountability
  • Changes should be traceable to Requirements Traceability Matrix (RTM)
    • Minimises Easter eggs and bells-and-whistles
  • Changes must be approved
  • Change logs must be preserved for future review
  • Log should include:
    • Code file (where)
    • Person (who)
    • Timestamp (when)
    • Details of the change (what)
  • Physical protection: disaster recovery and server hardening to source server
  • Environment for static code analysis should be controlled.
  • Version control and maintain a list of managed code.

Build Tools and Environment Integrity

  • Security controls should be applied during build and in build environment.
  • Limit owners and actions on the build system.
  • Activities on the build environment should be traceable.
    • When using automation, the individual owning the account should be traced.

Testing for Code Security

  • Good tools should have following characters:
    • Identify
    • Classify
    • Minimal false alert
    • Indicate source of vulnerabilities
  • Static:
    • Source Code Analysers: crawl source code, find weaknesses, based on what is known.
      • Degree of coverage should be configurable, complete coverage should be on by default.
      • e.g bugScout, Clang Static Analyzer, CodeCenter, CodeSecure, Coverity SAVETM, FindBugs, FindSecurityBugs, Rational AppScan Source Edition, Rough Auditng Tool for Security (RATS), Source Code Analyzer (Fortify), HP QAInspect.
    • Bytecode scanner: detect vulnerabilities in the byte code.
      • e.g FindBugs, FxCop, Gendarme, and Moonwalker.
    • Binary code scanner: detect vulnerabilities through disassembly and pattern recognition.
      • Advantage: no need to have the source code, ability to detect vulnerabilities created by the compiler.
      • Test the security of library function code or other dependency code available only as a binary.
      • e.g IDA Pro, SecurityReview (Veracode), and Microsoft’s CAT.NET
  • Dynamic:
    • Vulnerability scanners: scan networks and software applications for exploitable weaknesses at runtime.
      • Network: provide system patch and configuration auditing besides scanning the network
        • e.g Nessus, Core Impact, NeXpose, QualysGuard, GFI LanGuard, and SAINT
      • Web App: scan and detect web application vulnerabilities
        • e.g BurpSuite, w3af, Nikto, Paros proxy, AppScan, HP WebInspect, Samurai Web Testing Framework
  • Malware Detection & Combat: discover the presence of malware/malicious code.
    • Approach:
      • Create a baseline
      • Detect malware by scanning and monitoring anomalous executions that deviate from the baseline
    • Proactively detect vulnerabilities minimised malware infestation
    • Mostly use signature and heuristics
    • Malware combat:
      • Detecting and removing malware
      • Real-time protection, disallowing infection
    • e.g Microsoft Baseline Security Analyzer (MBSA), Microsoft Process Explorer (formerly Sysinternals), Trend Micro’s HiJackThis, Microsoft’s Malicious Software Removal Tool (MSRT), SUPERAntiSpyware, Malwarebyte’s Anti-Malware (MBAM)
  • Compliance Validation: determine how well an prescribed security plan is compliant with regulatory or privacy mandates.
    • Predominantly for information disclosure, particularly financial and health data security breaches
    • Often in form of questionnaires
    • PCI DSS Self-Assessment Questionnair

Security Testing Controls

  • Identification and characterisation of prospective risk requires management attention.
  • Risk assessments:
    • Identify and manage existing risks and address any new or emerging risks.
    • The process needs to be standardised to be applied across all aspects.
    • For product integrity assurance, an explicit process is needed to demonstrate the fulfillment of contractual terms.
  • Steps to create security testing controls
    • Initiation:
      • Define roles and responsibilities
    • Identification:
      • Identify and prioritise issues at each level and components
      • Usually done with acquisition and line managers
    • Security testing plan
      • Define audit and control activities
      • Identify required standards and practices
      • Integrate with project management plan
    • Implement procedures to guide the testing
      • Provide training
    • Implement testing process
      • Assign roles and responsibilities
      • Develop schedules
    • Define and perform monitoring
    • Issue resolution
    • Periodically review the program
  • Must provide sufficient documentation to prove the compliance with the contract.
  • Test outcome must comply with the compliance, any non-compliance must be resolved beforing continuing.

Software SCRM during Acceptance

  • Anti-Tampering Resistance and Controls:
    • Make sure it cannot be tampered, tampering must be reversible
    • Can be achieved by cryptography, hash must be computed before transfer
  • Authenticity and Anti-Counterfeiting Controls:
    • Must assure authenticity of origin and anti-counterfeiting control
    • Code signing can provide genuineness of pedigree confidence
    • Can also use license-checking and online product registration
    • Implement a whitelist of authorised to execute
  • Supplier Claims Verification
    • Determining if there are any known vulnerabilities, also can do black box testing after approval
    • Better to use 3rd party for objectivity and neutrality
    • Checklist is not enough, need to verify

Software SCRM during Delivery

Chain of Custody

  • Characteristics: authorised, transparent, verifiable
    • Usually achieved through Configuration Management
  • Secure Transfer:
    • Session encryption, end-to-end authentication
    • Transport layer: TLS/SSL
    • Network layer: IPSec
  • Code Escrows
    • Three parties:
      • Acquirer
      • Publisher
      • Escrow agency (mutually agreed 3rd party)
    • A form of risk transference
    • Code escrow protects the licensor’s IP and supplier’s wishes to retain the rights
    • Verification & validation:
      • Retrieval
      • Compilation
      • Versioning
    • Ransomware: original developer no longer maintains it and the software is under free lincense
  • Export Control and Foreign Trade Data Regulations Compliance
    • Supplier obtains export licenses, unless otherwise arranged
    • Common requirements:
      • Export Control Classification Number (ECCN)
      • Export list numbers
      • Commodity code classification for foreign trade statistics
      • Country of origin
    • SAFE framework, developed by World Customs Organization (WCO)
      • Establishing standards that provide supply chain security promoting certainty and predictability
      • Enabling integrated supply chain management for all modes of transport
      • Enhancing the role, functions and capabilities of Customs
      • Promoting the seamless movements of goods through secure international trade supply chains
    • SAFE strengthen the two pillars
      • High-risk deliveries (Customs-to-Customs)
      • Customs and Businesses (Customs-to-Business)
  • Configuration management: the organization and maintenance of software objects.
    • To control the evolution of software in a way that preserves the integrity of the system.
    • Define and enforce integral management control over the handling of the software assets.
    • Establishes product baselines and ensures rational changes over time.
    • The most important process in the assurance of continuing supply chain integrity.
    • Need three elements in the process:
      • Development: to support the identification process.
      • Configuration management: to support authorisation and configuration control.
      • Software Quality Assurance (SQA): to support verification.
    • Configuration management and SQA are the key to ensure the configuration is accurately known.
  • Software Configuration Management (SCM)
    • Assurance of a chain of custody.
    • Ensure the state of all product baselines is known at all times.
    • Provide methods for easy monitoring and error/cost reduction.
  • Advantages of configuration management and SCM:
    • Maintains configuration items integrity.
    • Allows for rational evaluation and performance of change.
    • SCM gives top-level management direct input into the ICT assets.
    • SCM provides a basis to measure quality and to improve the process
      • Make testing and quality assurance (QA) easier
      • Remove error-prone steps from product release management
      • Provide traceability of related components
      • Ease change management and problem-tracking challenges

System-of-Systems Integration

  • Aim: to produce synergy from the linkage of all of the components.
  • System-of-systems arrays are not specifically supply chain issues.
    • They do not involve movement on a supply chain ladder.
    • The integration itself is relevant in terms of supply chain risk management.
  • Responsibility of interoperability belongs to System Engineering.
    • Identifying and characterising, conceptualising, and analysing system-of-systems applications
    • Supported by continuous system modeling, agent-based modeling, and Unified Modeling Language (UML)
    • Guided by abstraction, modularity, and information hiding

Publishing and Dissemination Controls

  • Software needs to be moved in the supply chain and maintain the “as built” state.
  • Product license is the most obvious control
    • Certifies the authenticity
    • Protect the supplier in that they brand the product as theirs
    • Protect the acquirer in that they underwrite trust based on the supplier’s reputation for security
  • Non-repudiation: ensure the dissemination is authentic
    • Encryption
    • Authentication
    • Access control
    • Digital signing
    • Public key transfer
    • Checksums

Software Authenticity and Integrity

  • Authentication follows the same standard principles for non-repudiation.
    • MiTM has to be eliminated.
  • Controls at digital level:
    • Digital signing organizations (certificate authorities)
    • Public Key Infrastructure (PKI) certificate authority
    • Specialized checksums and hashes
  • Determining the level of integrity of a components is always a challenge.
  • Assurance means:
    • Targeted bench checks
    • Static and dynamic tests
    • Audits
    • Reviews
  • Counterfeits emulate the legitimate part, hence are difficult to identify.
  • Anti-counterfeiting methods
    • Trusted foundry vetting
    • Other forms of direct supplier control

Product Deployment and Sustainment Controls

  • A part of Configuration Management
  • Configuration management is a strategic process
    • Pre-requisite: configuration identification scheme, established during requirements analysis
    • All components are identified and uniquely labeled
    • Decisions of the configuration are made outside of configuration management
    • Change occurs when new baselines are created through the promotion or release process.
    • Labeling and identification should reflect new baselines
  • Configuration management incorporates two processes:
    • Configuration control
    • Verification control
  • Management activities involved to implement the controls:
    • Change process management:
      • Authorisation
      • Verification control
      • Release processing
    • Baseline control:
      • Change accounting
      • Library management
    • Configuration verification:
      • Status accounting (to verify compliance with specifications)

Software Bill of Materials

  • A list of the constructs and versions within a build for tracing vulnerable components.

Software SCRM during Deployment (Installation/Configuration)

  • Purpose: to determine the operational readiness of the software: Operational Readiness Reviews (ORR)
    • Operational ready and resilient to threats
    • Perimeter defense controls
    • Ensuring the security during integration
  • Secure Configuration
    • Secure configuration settings, details of risk when not met
    • Adhere Security Content Automation Protocol (SCAP)
  • Perimeter (Network) Security Controls
    • Define perimeter security controls
    • Threats increase proportionally with the number of suppliers
  • System-of-Systems (SoS) Security
    • High degree of connectivity
    • Interdependencies
    • Lack of control
    • Should undergo attack surface analysis: threat modeling, secure coding and security testing

Software SCRM during Operations and Maintenance

  • Purpose: to assure reliable functioning in operation.
  • Runtime Integrity Assurance
    • Prior installation: anti-tampering and authenticity assurance
    • Runtime: code signing
    • Trusted Platform Module (TPM): in conjunction with signed code, assures both hardware and software.
  • Patching and Upgrades
    • Discovered vulnerabilities must be managed
    • Need an enterprise-wide patch management process
      • Update notifications prior to patching
      • Secure location to get the patch
      • Publication of valid checksums for the patch
      • Publication of test validation suites to evaluate the path
      • A mechanism to report post patching findings
      • A critical part of good supply chain risk management practice
  • Termination Access Controls
    • Disgruntled employees: logic bombs and malicious code
    • After handed over from supplier
  • Custom Code Extensions Checks:
    • Threat modeling
    • Code review
    • System integration testing
    • Maintain chain of custody
  • Continuous Monitoring and Incident Management
    • Goal: evaluate effectiveness of security controls through periodic testing and evaluation.
    • Scanning, pen-test, IDS
    • Robustness of a continuous monitoring strategy is tied to active participation of people.
  • Sustainment: the operations and maintenance activity that follows delivery of the product.
    • Aim: to sustain the delivered product within its intended environment and to provide support.
    • Handle disruption of service
    • Generally considered to be outside of the supply chain, because its post-delivery nature.
    • Security update is a part of the supply chain
  • Operational plan
    • Covers post-development sustainment activities
    • Layout conditions and criteria for correct operation and intended environment
    • May include assistance and consultation
  • Patch management: obtains, validates and installs changes to the affected program’s code
    • Goal: to prepare and then distribute effective responses to security threats.
    • Can be viewed as an extension to the Change Management Process.
    • Patch management doesn’t concern construction, patches are usually from external sources.
  • Support:
    • Suppliers might be contracted to provide support
    • Customer requests need to be recorded
    • Sustainment is hgihly dependent on Configuration Management
  • Maintenance process
    • To change an existing software product while preserving its integrity
    • Control changes in a way that preserves the integrity and provides a basis for measuring quality

Monitoring and Incident Management

  • Incident: any event that discrupts normal operation.
  • Incident Management Role: to maintain the incident response capability of the organization over time.
  • Incident Management involves:
    • Monitoring: e.g IDS and IPS
    • Analysis
    • Response: applies to both foreseen and unforeseen events
      • The difference is if the response steps are planned ahead or not
  • In a supply chain, needs to distinguish the presence of a potential violation or a breakdown.
  • When detected a new threat, submit to a central registry.

Vulnerability Management, Tracking and Resolution

  • Two parts of vulnerability management
    • Identification and repair:
      • Inspection
      • Tests
      • Audits
    • Patching: usually after product release
      • Need to be issues in a timely fashion
      • Patches have to be applied when received
        • e.g SQL Slammer virus (patches available but no one applied)
  • All vulnerabilities need to be tracked and managed.

Supplier Transitioning

  • During the transition, a component moves from the developer to the integrator
  • Challenges:
    • Assuring component integrity at the interfaces
      • Need a transitioning plan
    • IP rights (small components may have different licensing terms)
      • Management control needed in the transition plan
  • Transition plan
    • Label and baseline individual components
    • Maintain components in escrow
    • Testing, review, audits at each transition level
    • Describe the process by which certification and authenticity will be underwritten

Software SCRM during Retirement

  • Decommissioning from operation
    • Decommission can happen at anytime
    • If data is needed after retiring a software, the data needs to be V&V and securely migrated.
  • Examples of software retirement
    • Partial re-use of components
    • Termination access control
  • Disposal of the data
  • Mechanisms for data disposal:
    • Media sanitization
    • Overwriting (formatting) data
    • Disk degaussing
    • Physical destruction
    • Removal of sensitive information
    • Cryptographic keys
  • Notes:
    • When acquirers fail to establish end-of-life decommissioning or disposal requirements or rules, the likelihood of unauthorised access and disclosure threats increases considerably.

Examples

Software Supply Chain Risks

  • Insufficient validation and sourcing of suppliers.
  • Contractual language does not take into account security requirements.
  • Unintentional design defects and coding errors that allow for exploitable vulnerabilities.
  • Introduction of malicious logic code by unauthorised parties after the software is developed.
  • Failure in logistics management resulting in distribution of code without adequate access control checks.
  • Improper code publishing processes that do not assure authenticity of code origin.
  • Inadequate configuration controls leading to insecure installation and deployment.
  • Failure in vulnerability and patch management processes that introduces risk during operations.
  • Inadequately trained personnel that fail to communicate assurance requirements to the supplier and/or attest the existence and effectiveness of technical controls in the acquired software.

Software Supply Chain Risks Management Common questions

  • Does the supplier have a security development lifecycle (SDL)?
  • Is the supplier location where the code is developed secure?
  • Is the data secure when it is processed, transmitted between suppliers, and stored?
  • Is the communication between the suppliers secure?
  • Can the supplier assure that the software or service produced is authentic and tamper-proof?

Generic Software Acceptance Criteria

  • The Supplier shall provide all operating system, middleware, and application software to the Acquirer security configured by Supplier in accordance with the FAR requirement based on 44 USC 3544 (b) (2) (D) (iii).
  • The Supplier shall demonstrate that all application software is fully functional when residing on the operating system and on middleware platforms used by the Acquirer in its production environment, configured as noted above.
  • The Supplier shall NOT change any configuration settings when providing software updates unless specifically authorised in writing by the Acquirer.
  • The Supplier shall provide the Acquirer with software tools that the Acquirer can use to continually monitor software updates and the configuration status.
  • At specified intervals by the Buyer, the Supplier shall provide the Acquirer with a comprehensive vulnerability test report for the suite of applications and associated operating system and middleware platforms used by the Acquirer in its production environment, configured as noted above.
  • The Acquirer and Supplier agree to work together to establish appropriate measures to quantify and monitor the supplier’s performance according to the contract requirements. Specific guidance should include types of measures to be used, measures reporting frequency, measures refresh and retirement, and thresholds of acceptable performance.
  • The Supplier shall provide all operating system, middleware, and application software to the Acquirer free of common vulnerabilities as specified by the Common Vulnerabilities and Exposures (CVE®)—The Standard for Information Security Vulnerability Names that can be retrieved from http://cve.mitre.org/
  • The Supplier shall provide all operating system, middleware, and application software to the Acquirer free of common weaknesses as specified in the Common Weakness Enumeration, A Community-Developed Dictionary of Software Weakness Types that can be retrieved from http://cwe.mitre.org/

Supplier Evaluation Questions

  • Process related: Secure SDLC
    • How is the software development process structured?
    • What are the artifacts generated?
    • Will the software development process be outsourced and if so, what checks and balances exist that require validation?
    • Do you have a threat modeling process, and is there a threat model for the software you are designing?
    • What kind of reviews (design, architecture, code, security) do you conduct?
    • How is the software tested against functional and security requirements?
    • What are the protection mechanisms in place to ensure that only authorised individuals can access the code?
    • Has the software been certified and attested as secure by an independent third party?
    • How current and accurate is the documentation that comes with the software?
  • People related:
    • What is your training program and the frequency in which your employees (and non-employee personnel) are trained in the latest security threats and controls to address threats?
    • What is your background checks and screening process before onboarding employees?

Technical Controls

  • Assurance of proper resource management
  • Proper use of data structures
  • Proper reuse of testing practices
  • General software engineering best practices
    • Proper commenting
    • Variable naming conventions
    • Code structure