Domain 7. Software Deployment, Operations, and Maintenance

Installation and Deployment

  • SDLC can be broken into two phases:
    • Development
    • Sustainment, i.e, Installation and Deployment
  • Sustainment: embed a product into the target environment.
    • Establish Sustainment policies and procedures
    • Include a mechanism for receiving, tracking, and resolving problem reports
    • Change management
    • Sustainment is not necessarily a part of the SDLC
    • Sustainment that involves the supplier should be planned ahead and contracted.
    • Sustainment is the transitionary stage between development and long-term use.

Installation Validation and Verification

  • Purpose: to ensure the software functions as described in the Sustainment Plan.
    • Establish procedures for testing and verifying the installed product.
    • Ensure the product is free of known defects (e.g through CWE)
    • Establish a plan for changeover if the new product is to replace an old product.
  • When the product is passed onto the customer, it’s their role to V&V the product.
  • Bottom line: changes should not violate existing SLA and performance metrics

Hardening

  • The processes of locking down a system to the most restrictive level so that it is secure.
    • Minimum Security Baseline: minimum security levels that all systems must comply to.
    • Effective against vulnerabilities due to insecure, incorrect and default configuration.

Environment Configuration

  • Pre-installation checklists:
    • Ensure needed parameters for configuration
    • This is not a guarantee
  • Common violation of Least Privilege: granting admin rights when installed.
    • Development/test environment should match production environment to avoid this.
  • Considerations:
    • Test/default accounts need to be turned of.
    • Unnecessary services should be removed from all environment.
    • Access rights need to be denied by default and granted explicitly even in development/test.
    • Changing platform may affect security.

Release Management

  • Release management: the process of ensuring that all changes made to the computing environment are planned, documented, tested and deployed with least privilege, without negatively impacting any existing business operations, customers, end-users or user support teams.
    • Ensure the integrity of the baselines.
    • Maintain confidence in product integrity.
  • Software configuration management plan (SCMP) is necessary to manage the process.
  • Configuration Management Database (CMDB):
    • Document and manage configuration
    • Mandated by ISO/IEC 15408
  • Version control: the process of labeling different releases of software so that operations can manage their software deployments to specific configurations.
  • Repositories for release:
    • Controlled: for the current, official, authorised version of each product baseline.
    • Dynamic: for programmers to experiment for an acceptable and proper change.
    • Archive: for storing a current baseline that has been replaced.
  • Useful lifecycle: the lifecycle of the product after release.
  • Key notes:
    • Software should be built for release, not for debug.
    • Previously fix bugs may reappear (i.e regression).
    • The product has to be proved correct prior to re-integration.

Bootstrapping and Secure Startup

  • Bootstrapping (a.k.a booting): any type of function that ensures self-sustaining operation.
    • Ensure operational effectiveness.
  • Initial Program Load (IPL): software startup processes should not impact C-I-A.
    • The first thing to protect to maintain Trusted Computing Base (TCB)
      • e.g, Power On Self Test (POST), OS loading, services running and configuration loading
    • BIOS can do destructive memory check during POST to prevent information disclosure.
      • BIOS may overrite a portion of memory.
      • Password protection is only an access management control, not integrity check.
  • Secure startup: all functions that assure the environment’s TCB integrity when the system starts.
    • Trusted Platform Module (TPM): stores a fingerprint for the system (created during boot).
  • Interruption during boot may breach availability.

Customer Support

  • Customer Support: ensure that the customer’s decision is documented and properly implemented.
    • May also provide day-to-day technical support and consultation.
      • e.g training, documentation, and other support services.
    • Customer support requests need to be coordinated by a single entity, i.e Configuration Manager.
    • The entire process needs to be monitored, an official sign off is needed to ensure the completion.
  • Customer-use process: ensure effective interactions between the originators and its resolution.
    • Customers can choose between a temporary fix and a proper fix.

Configuration Management

  • Configuration Management: ensure management control over the intangible assets of an organisation.
  • Software Configuration Management (SCM): organisation and maintenance of software objects.
    • Ensures the integrity of all configuration items
    • Permits the rational evaluation and performance of changes to the product and process
    • Provides the decision makers with visibility into the development and sustainment processes
  • Major stages in SDLC that concerns Configuration Management
    • Development:
      • Implements the identification and baseline requirements.
    • Sustainment:
      • The primary activity consists of operations and maintenance.
      • Ongoing issues are addressed through reporting, analysis, and authorisation.
    • Assurance:
      • Maintains product integrity over time.
      • Supported by verification and validation activities.
    • (Sustainment and Assurance are the cornerstones of the overall SCM process)

Organizing the Configuration Management Process

  • Three roles:
    • Customer: responsible for the maintenance of the product after release.
    • Supplier: responsible for managing the configuration of the product prior to release and any subcontractors.
      • Maintain the product.
      • Ensure product security.
      • Provide configuration management plan.
      • Ensure subcontractor’s understanding and participation.
    • Producer: overseers for ensuring the requirements are carried out.
  • Two processes in configuration management:
    • Configuration control
    • Verification control
  • Documentation Control: a means of ensuring that system changes are approved before being implemented, only the proposed and approved changes are implemented, and the implementation is complete and accurate
  • Three interdependent management entities:
    • Change process management:
      • Change authorisation
      • Verification control
      • Release processing
    • Baseline control:
      • Change accounting
      • Library management
    • Configuration verification:
      • Compliance verification

Configuration Management Roles

  • Configuration manager:
    • Receive and document all software change requests
    • Manage authorisations and verify the changes.
    • The interface between the user community and the configuration management process (a critical point of failure)
  • Baseline manager:
    • Ensure all configuration items are identified, accounted for and maintained according to the identification scheme.
  • Verification manager:
    • Ensure product integrity.
    • Maintain documentations.

The Configuration Management Plan

  • Describe the activities
  • Describe the timing
  • Describe the units for performing each activity
  • Describe the structure and maintenance of Product Identification Number (PIN).
  • Minimum requirement:
    • Change management
    • Baseline management
      • Baselines are approved for the lifecycle.
      • All prior baselines represent collective memory of past configurations.
    • Verification management roles
    • Methods for establishing and maintaining the configuration identification scheme
  • Management approval must be clearly defined.

The Configuration Management Process

  • Purpose: establish and maintain the integrity of the software items and make them available to stakeholders.
    • Process implementation
    • Configuration identification
    • Configuration control
    • Configuration status accounting
    • Configuration evaluation
    • Release management and delivery
  • Configuration Identification Scheme (the foundation):
    • Represent the basic structure/configuration of the software.
    • Items defined need to be numbered: Product Identification Numbers (PINs).
  • Change Control purpose:
    • Ensure the completeness, consistency and correctness of each of the items.
    • Keep track of changes:
      • Configuration Management Database (CMDB)
      • Configuration Management System (CMS)
      • Entities seeking ISO/IEC 15408 (Common Criteria) accreditation are expected to maintain a comprehensive CMS.
  • Configuration Control Board (CCB): authorise changes to baselines at defined levels of authority
    • High level board: top-level policy makers
    • Medium level board: each product’s major components
    • Low leve board: technical level
  • KEy notes:
    • Define management role to approve changes for the baseline.
    • Audits confirm that the processes continue to be effective.
    • Configuration management should also be managed in a disciplined fashion.

Configuration Management Process Implementation

  • All changes have to be verified for correctness before reintegrating the change into the current baseline.
  • Output: a complete, correct and fully documented plan for the entire configuration management process.

Configuration Identification

  • Setup an Identification Scheme.
  • Establish an approach to identifies baselines.
  • Version control for the baselines.

Configuration Control

  • Key notes:
    • Most visible to the end user
    • Has the biggest payoff for members of the organisation
    • Audit information includes the reason for the modification and who authorised it
  • Procedure:
    • Request reception
    • Request analysis, accompanied by a resource analysis
      • Configuration management decisions need to be driven by in-depth analysis
    • Change agent implement the change
    • Verifications, reviews
    • Release the change
    • Establishes an audit trail

Configuration Status Accounting

  • Show the status and history of controlled software items (including baselines):
    • Number of changes for a project
    • Latest software item versions
    • Release identifiers
    • Number of releases
    • Comparisons of releases

Configuration Evaluation

  • Verify the functional and physical completeness of the software items against the requirements.
    • Requirements are communication through Statement of Work (SOW)
  • Criteria: whether the design can be confirmed to reflect an up-to-date description of the product and that the code is acceptable.

Operations and Maintenance

  • Processes needed:
    • Monitoring and reporting
      • Ensure straightforward reporting with decision makers
    • Explicit enforcement
      • Problem resolution process
    • Ensure professional knowledge of the practioners
    • Define an operation baseline
  • Deployed software usually has a residual risk level accepted by the business, but may change over time.
  • Key notes on operation:
    • Purpose: perform routine tests and reviews to ensure the system continues to function as required.
    • Operation is not a part of SDLC, it starts when the product is released.
    • Operation activities are often written into the contract to provide post release sustainment services.
  • Key notes on maitenance:
    • Purpose of Operations and Maintenance: ensure that any problem or request for modification is responded to appropriately.
    • Maintenance functions independently of development.
    • Maintenance handles analysis of the problem report.
  • All changes have to be verified prior to releasing the changed software for operational use.
  • Resource:
    • ISO 12207:2017 Systems and software engineering - Software life cycle processes

Operations security

  • Aim: to operate the software product in its intended environment.
    • Assurance on product effectiveness and product support for community
    • Staying secure or keeping the resiliency levels of the software above the acceptable risk levels
    • Routine work, instead of creative work
    • Concerns most people, hence usually the most expensive IT expense
  • Documentations
    • Overall operational planning
    • Standard Assurance Plan: guide the routine tests and reviews
    • Organisation-wide policy: ensure customers are given adequate advice
  • Hardware
    • Networking devices: switches, routers, firewalls, etc.
    • Communication devices: phones, fax, PDA, VoIP devices, etc.
    • Computing devices: servers, workstations, desktops, laptops, etc.
  • Software
    • In-house developed software
    • 3 party software
    • OS
    • Data
  • Media
    • USB, tapes, hard drives, optical CD/DVD
  • People
    • Employees
    • Non-employees

Operation security control types

  • Detective:
    • Build a historical evidence
    • Directly related to reliability
    • Passive
    • eg: audit, IDS
  • Preventive:
    • Make the attacks difficult
    • Directly related to resiliency
    • Reduce impact
    • e.g: input validation, output encoding, bounds checking, patching, IPS
  • Deterrent:
    • Dissuade an attacker from continuing
    • Between preventive and passive
    • e.g: auditing when the users is aware
  • Corrective:
    • Provide the recoverability of software assurance
    • e.g: Load balancing, clustering, failover
  • Compensating:
    • Controls required when the prescribed controls cannot be met due to technical or business constraints.
    • Usually applied when compliance is not achieved
    • PCI DSS requires compensation controls to satisfy the following criteria
      • Meet the intent and rigor of the original requirement
      • Provide a similar level of defense as the original requirement
      • Be part of a defense in depth implementation so that other requirements are not adversely impacted
      • Be commensurate with additional risk imposed by not adhering to the requirement

Operations Process Implementation

  • Aim: to perform a standard set of activities and their constituent tasks on a day-to-day basis
    • Monitor and assure the effective operations and alert management when for abnormallies
    • Document and track all user requests.

Connecting Operation to Change

  • Operations act as the necessary “front end” to configuration management.
  • Operator’s duty:
    • Establish routine schedules and procedures:
      • Assurance
      • Reception
      • Recording
      • Tracking
      • Modification
    • Provide feedback on routine performance
    • Updating Software Change Management System
    • Implement organisational management functions to ensure that all requests are processed

Planning for Secure Operation

  • Strategic planning:
    • Develop a plan that aligns with the organisational policies for the secure sustainment of a software
    • Describe the specific activities
    • Develop a strategy and standards to carry out the activities
  • Deploy the plan as a day-to-day routine
    • Specify practical routines
    • Specify a feedback mechanism:
      • Receiving
      • Recording
      • Resolving
      • Tracking
  • Efficient communication
    • Communicate cost and impact to stakeholders and decision makers
    • Specify a mechanism for unresolved issues
    • Specify procedures for verification and validation
  • Maintenance
    • Specify a mechanism for maintaining all documentations
    • Specify procedures for operational information gathering and update

Operational Monitoring and Control

  • Operation is generally responsible for the routine testing on every release
  • Ensure all operational aspects perform as required
  • Decision maker authorises for operational use
  • Ensure the product has been delivered back for operational use and communicated back to the requester

Customer Support

  • Operations process:
    • Provide all necessary advice and product support
    • All requests must be tracked and recorded
  • Operations manager (may also be the Configuration manager)
    • Customer request (Change Requests, i.e CRs) distribution
  • Establish a process to handle community requests
    • New feature requests are analysed and planned
    • Operation’s responsibility to communicate the changes to the requesters
  • All resolutions are ensured by the customer support process
    • Operation is dependent on configuration management
    • Short term fix vs long-term fix, the requester’s choice
  • Operators always provide assistance and consultation to the users
    • Training, documentation, other support services

Ensuring the Service Operation

  • All software are continously ensured to operate in the intended environment
  • Operations also monitor routine activities against defined criteria (or SLA)
  • Monitor for any risks that may arise

The Software Maintenance Process

  • Purpose:
    • Provide cost effective modifications and operational support of the software.
    • Control change requests and preserve software integrity and quality.
  • Maintenance operation should never function as a stand-alone element, follow:
    • Planning
    • Control
    • Assurance
    • Communication
  • Maintenance strategy:
    • Centers on understanding the impacts of changes
    • Identify all aspects affected by the change
    • Update documentation
    • Oversee all modifications and conduct tests
  • Responsibilities:
    • Migrate all upgrades to the user
    • Communicate to all affected parties
    • Ensure integrity of all software
    • Retirement of obsolete products
  • Maintainer:
    • Execute maintenance process at project level
    • Establishe a standard infractracture for activity execution
    • Enhance the process
  • Documented problems are progressed through a resolution procedure
  • Maintenance plan has to describe a mechanism for interfacing between maintenance and problem resolution

Monitoring

  • Goal:
    • Monitor the state of assurance of the system and incident response
    • Maintain an ongoing state of trust among stakeholders
  • Pre-requisite:
    • Routing and reporting responsibility
    • Enforcement mechanism
    • Conflict resolution process
  • Simple rules:
    • Entity conducting the review should not report to the same entity under the review
    • Reporting line should be relatively local rather than distant
    • Reduce reporting layers between review team and senior site manager
  • Human factors (operational review)
    • Utilise personnel with a sustainment focus rather than development
    • Review team should inspect operations to align with organisational goal, should have technical capabilities
    • Review team should be able to interpret results and act upon it
  • Monitoring requirement
    • Should be pre-defined during requirement phase:
      • What to log
      • How often
      • How to use the log
  • Word of wisdom:
    • What is not monitored cannot be measured and what is not measured cannot be managed.
    • The defender has the role of playing vigilant all the time while the attacker has the advantage of attacking at will anytime.
    • Logic Bombs can be planted by an insider and when the network is not monitored, the likelihood of these are higher.

Why monitoring

  • Validate compliance
  • Demonstrate due diligence
  • Provide evidence for audit defense
  • Assist in forensics investigations
  • Determine the security setting is not below the security baseline
  • Assure no C-I-A impact
  • Detect insider and external threats
  • Validate the precense of appropriate controls
  • Identify new threats
  • Validate the overall state of security.

What to monitor

  • Any system, software or their processes, check:
    • Determine monitoring requirement
    • Governance requirements, regulatory policies
  • Any operations that can have a negative impact on the reputation
    • Environments of low trust must be monitored, e.g. DMZ
  • Physical access
    • PCI DSS mandates physical access to cardholder data must be appropriately restricted

Ways to Monitor

  • Scanning:
    • Determine the makeup of the computing ecosystem
  • Logging:
    • Preventing, detecting or mitigate data compromise impacts
    • National Computer Security Center (NCSC), A Guide to Understanding Audits in Trusted Systems:
      • Make it possible to review access patterns and histories and the presence and effectiveness of various protection mechanisms (security controls) supported by the system.
      • Make it possible to discover insider and external threat agents and their activities that attempt to circumvent the security control in the system or software.
      • Make it possible to discover the violations of least privilege principle. When an elevation of privilege occurs (e.g., change from programmer to administrator role), the audit mechanisms in place should be able to detect and report on that change.
      • Be able to act as a deterrent against potential threat agents. This requires that the attacker is made aware of the audit mechanisms in place.
      • Be able to contain and mitigate the damage upon violations of the security policy, thereby providing additional user assurance.
  • Intrusion Detection:
    • Monitor potential attacks
    • Bastion host: a fortified system exposed to external attack and illegal entry.
      • On public side of DMZ, not protected by firewall
      • Deterrent and detective
      • Effective against script kiddies and curious non-serious attackers
      • Can be used as a honeypot, resons:
        • Distracting the attackers
        • Acting as warning systems
        • Conducting research on newer threats
    • Enticement is not necessarily illegal, evidence from honeypots may/may not be admissible in court
    • Entrapment: encouraging people to commit a crime is illegal, evidence not admissible

Metrics in Monitoring

  • Metrics are measurements information.
  • Initial drive before metrics: Fear, Uncertainty and Doubt (FUD)
  • KPI, used by organisations to measure the progress toward goals.
  • Good metrics should be:
    • Consistent
    • Quantitative
    • Objective
    • Relevant
    • Inexpensive

Audits for Monitoring

  • Audits are monitoring mechanisms by which an organisation can attest the assurance aspects.
    • Must be conducted periodically
  • Rationals
    • Determine that the security policy of the software is met.
    • Assure data C-I-A.
    • Make sure that authentication cannot be bypassed.
    • Ensure that rights and privileges are working as expected.
    • Check for the proper function of auditing (logging).
    • Determine if the patches are up-to-date.
    • Examine if the unnecessary components are disabled/removed.
    • Reconcile data records when they are maintained by different people or teams.
    • Check the accuracy and completeness of authorised transactions.
    • Restricted physical access to sensitive data.

Incident Management

  • Goal: to maintain an incident response capability for the organisation over time.
    • Incident management has to be planned ahead
    • Upper-level management has to be involved
    • Has to be executed as a specialised function
    • Need a single entity for incident management
  • Incident response process:
    • Monitoring
    • Analysis
    • Response actions
  • Events: any action that is directed at an object which attempts to change the state of the object.
  • Alerts: flagged events that need to be scrutinized to determine if it is an incident.
  • Incidents: alerts that violate the security, any event that disrupts normal operation of the software or system.
  • Types of Incidents:
    • DoS
    • Malicious Code
    • Unauthorised Access
    • Inappropriate Usage (violates the acceptable use)
    • Multiple Component (encompass two or more incidents)
  • Diagnosis Matrix:
    • A matrix that helps diagnosing incidents and proper response actions
    • Lists incident categories and the symptoms associated with each category, may include advice.
  • NIST SP 800-61 Computer Security Incident Handling Guide
    • Detection
    • Validation and classification
    • Mitigation
    • Establish procedures
    • Communication

Monitoring and Incident Identification

  • Incident response is initiated when a potentially harmful event occurs.
  • Incident reporting ensures that every possibly damaging event gets an organisationally sanctioned response.
  • Monitoring must:
    • to identify a potentially harmful event in as timely a fashion as possible
    • gather objective data for decision makers
    • provide most timely incident analysis
  • Incident Identification: to distinguish a potential threat

Incident Reporting and Management Control

  • Source of incidents:
    • Major events
    • Routine defects
    • Intentional malicious objects in code
  • Key notes:
    • Incident report is filed to the incident manager.
    • Incidents should be handled according to the process despite the nature of the incidents.
    • KPIs can be determined by Threat Modelling.

Anticipating Potential Incidents

  • Incidents are either potential or active
    • Potential:
      • Defects, unforeseen flaws, notified existing vulnerability
      • Can be patched before it happens
    • Active:
      • Already materialised

Responding to Active Incidents

  • When handling an active incident, there lacks time to develop a proper response
  • For incident response team:
    • Constraint the damage
    • Study the triggers
    • Oversee the patch implementation

Establishing a Structured Response

  • Ensure that adequate preparation has taken place to respond to incidents.
  • Incident response manual
    • Definition of terms
    • Specify roles and responsibilities
    • Specify personnel and authority

Ensure Enough Resources

  • Inappropriate response
    • Under response may lead to losses
    • Delays may increase risk exposure
    • Errors may impede legal actions againt malicious parties
  • Metrics can provide information on the effectivenss, good metrics:
    • Incident occurrence and detection
    • Detection and response
    • Response and containment
    • Containment and resumption
  • Key notes:
    • Make sure the right resource is available.
    • Establish a balance of appropriate response.
    • Escalation of decisions should be based on analysis and appropriate guidance.

Managing the Incident Response Team

  • Team manager: determine which members of the team are immediately needed.
    • Goal: provide the optimum response to every known aspect of the incident without deploying unnecessary or unneeded personnel.
    • Analyse the following:
      • Number and type of affected applications and operating systems
      • The system assets that were attacked and the sophistication of the attack
      • Business impact
      • Adverse publicity
      • Internal political issues
      • Corporate liability
  • Expert software analysts and programmers
  • Cybersecurity and computer crime specialists
  • (optional) legal and governmental or public affairs experts

Incident Response Process

  • Preparation: limit the number of incidents by implementing controls from the risk assessments.
    • Establish policies and procedures
    • Create and train an incident response team
    • Perform periodic risk assessments and reduce the identified risks
    • SLA, document actions and maximum response times
    • Identify additional relevant personnel
    • Acquire tools and resources that the IRT personnel can use.
    • Conduct awareness and training
  • Detection and Analysis
    • Log analysis process
      • Collection
        • NIDS and HIDS logs
        • Network Access Control Lists (ACL) logs
        • Host logs
        • Application logs
        • Database logs
      • Normalization: parsing the logs to glean information from it
        • The quality of the incident handling process is dependent on the quality of the incident data that is collected
      • Correlation: correlate the events to threats or threat agents
        • Primary reason is to deduce patterns
        • Secondarily, it can be used to determine the incident type
      • Visualization
        • Continuously monitoring
        • Provide mechanisms for both external and internal to report incidents
        • Ensure that the appropriate level of logging is enabled
        • Centralized logging and create a log retention policy
        • Profiling so that any abnorms are alerted and should warrant attention
        • Maintain a diagnosis matrix
        • Document and timestamp all steps, could be used for court
        • Establish a mechanism to prioritize the incidents
          • Should not be on a first-come first-serve basis
  • Containment, Eradication and Recovery
    • Containment strategies must be based on the type of the incident
      • Delay containment can be useful, but is dangerous and have legal ramifications
      • Criteria to determine the right containment strategy:
        • Potential impact and theft of resources
        • The need to preserve evidence (discuss with legal team)
        • Availability of service
        • Time and resources needed to execute the strategy
        • The completeness and effectiveness of the strategy
        • The duration and criticality of the solution
        • The possibility of the attack to cause additional damage
    • Eradication
      • Need authorisation to perform
      • Contractual agreement for 3rd party data
    • Recovery: to restore the resource back to its normal working state
      • Need to handle repeating offenders
  • Post-Incident Analysis
    • Lessons learned
      • Provide the data necessary to identify and address the problem at its root
      • Help identify security weaknesses in the network, system or software
      • Help identify deficiencies in policies and procedures
      • Be used for evidentiary purposes
      • Be used as reference material in handling future incidents
      • Serve as training material for newer and lesser experienced IRT members
      • Help improve the security measures and the incident handling processes
    • Maintain an incidents database
    • Post-Incident Analysis needs to be conducted prior to communicating with affected agencies
      • Communication guidelines
    • Bare minimum content
      • What happened?
      • When did it happen?
      • Where did it happen?
      • Who was involved? and
      • Why did it happen?

Problem Management

  • Incident management: to restore service and business operations as quickly as possible.
  • Problem management: when the cause of an incident is unknown, it is said to be a problem.
    • To determine and eliminate the root cause
    • To improve the services provided to the business
    • To make sure that the same problem does not occur again
    • Include vulnerability tracking
      • Bug and vulnerability tracking and end-user support are inexplicably linked.
      • Proper data logging can improve the ability in correcting issues across releases.
    • Process:
      • Incident Notification
      • Root Cause Analysis
      • Solution Determination
      • Request for Change
      • Implement Solution
      • Monitor and Report
  • Incident management treats symptoms, Problem management addresses the root cause.
  • Permanent fix vs temporary workaround
    • Workaround is in when a permanent fix is unavailable in order to provide business continuity.
    • Once a permanent fix is identified, the workaround becomes a known error.
  • Root Cause Analysis (RCA):
    • Determine why the incident happened.
      • It’s important to identify and differentiate the symptoms from the underlying reason.
    • Litmus test: once the root cause is fixed, the problem shouldn’t happen again.
    • Fishbone Diagram: Ishikawa diagrams or cause and effect diagrams, for RCA
    • Use predefined categories for RCA
      • People: awareness, training or education
      • Process: non-existent, ill-defined
      • Technology, Network, Host, Software: coding, 3rd party component, API
      • Environment: Production, Development, Test
    • Output:
      • Workarounds
      • Known errors
      • Updated problem information
      • Management information
      • Request for changes
  • Impact Analysis
    • Type:
      • Corrective
      • Improvement
      • Preventive
      • Adaptive
    • Scope: a measure of the size, cost and time of the modification
    • Criticality: impact to the overall performance, safety, security
    • Process:
      • Determine if the problem realy exists, e.g Replication
      • Determine options, provide a mapping between options and costs
      • Develop options and produce a report with favoured option
      • Control board approval and create Statement of Work (SOW)
    • Impact Analysis for residual effects
      • Identify areas of continues trouble
      • Identify affected systems
  • Change manager:
    • Coordinate all communication
    • Monitoring
    • Management control
    • Reporting

Modification Implementation

  • Determine affected software versions.
  • Document all aspects of the structure and interfaces.
  • Maintainer (Change agent) implementation:
    • Determine the area of change and generate a specification.
    • Implement the changes.
  • Record actions taken on the affected components.
  • Test and review the changes for completeness and correctness.

Maintenance Review/Acceptance

  • Change manager conducts a review with requester to determine the integrity has been perserved.
  • Change agent ensures the satisfactory completion as specified in Statement of Work (SOW).
    • Maitainer connduct a review with the entity that wrote the SOW to attest the change.
  • Ensure the changes are properly integrated.
    • Authorising party provides approval for reintegration
    • Approval is based on the ability to map the modified components back into the system.
  • Final sign-off: simple note or audit.

Change Management

  • Goal: protect the enterprise from risk associated with changing of functioning systems.
  • Root cause identification -> (workarounds) -> recovery -> resolution
  • Change Management: the overall goal of Patch, Configuration and Vulnerability Management.

Patch and Vulnerability Management

  • Patch management is a crucial element of a secure production environment.
    • Patching is a subset of hardening.
    • Patching is reactive, patch/vulnerability management is preventative (proactive).
    • Incidents are more costly than managing patches.
  • Common patching mechanisms:
    • Hotfix or Quick Fix Engineering (QFE)
      • Functional or security patch.
      • Benefit: allows the organisation to apply the fix one at a time or selectively.
    • Service Pack
      • An update to the software that fixes known problems, usually a roll up of multiple hotfixes.
      • Benefit: multiple hotfixes (or QFEs) can be applied more efficiently
  • Main Challenge: the applied patch could cause a disruption of business (regression)
    • Patches need to be tested in a simulated environment beforehand
    • Test for backward compatibility
    • Test for security impact
    • Validate against and update minimum security baseline
  • Three primary remediations:
    • Installing patch
    • Adjusting configuration
    • Removal of affected software
  • Time frame: leave as little time between release and fix as possible
    • Observation: systems and software are most vulnerable shortly after a patch is released
  • Patch Management Steps:
    • Notification of the patch
    • Test the patch
    • Document the change along with the rollback plan
      • Estimated time
      • Success criteria
      • Rollback plan
      • Change request
    • Identify maintenance windows and patch time
    • Install the patch
    • Test the patch post-installation
    • Validate the patch not violating any security or compliance
    • Monitor the patch
    • Conduct analysis in case of rollback
      • Update minimum security baseline
  • Patch release schedules:
    • Immediate
    • Regularly shceduled
    • With product release
  • NIST SP 800-40 Guide to Enterprise Patch Management Technologies:
    • Establish a patch and vulnerability group (PVG).
    • Continuously monitor for vulnerabilities, remediations, and threats.
    • Prioritize patch applications and use phased deployments as appropriate.
    • Test patches prior to deployment.
    • Deploy enterprise-wide automated patching solutions.
    • Use automatically updating applications as appropriate.
    • Create an inventory of all information technology assets.
    • Use standardized configurations for IT resources as much as possible.
    • Verify that vulnerabilities have been remediated.
    • Consistently measure the effectiveness of the organisation’s patch and vulnerability management program, and apply corrective actions as necessary.
    • Train applicable staff on vulnerability monitoring and remediation techniques.
    • Periodically test the effectiveness of the organisation’s patch and vulnerability management program.

Backups, Recovery and Archiving

  • Provide business continuity
  • Backup before patching, ensure data integrity and restorability
  • If infected by malware, reinstall system and restore data from a secure place
  • Ensure appropriate encryption is applied
  • Ensure the recovery procedure is controlled
  • Ensure archieves are protected (retention of archieves are subject to regulations and org policies)
    • Former controlled baselines usually contain important information.
  • Retention Cycle: a complete set of backups needed to restore data.
    • Can be a full backup set or a full backup plus incremental sets

Secure DevOps

  • DevOps: a form of software maintenance where changes are put to production.
    • Implementation of the change
    • Post-change operational testing
    • Automated rollback
  • Risk can come from large amount of software changes (utilise automation)
  • Benefits:
    • Developers can see failures more quickly
    • Reduction of lengthy test cycles

Continuous Integration/Continuous Development (CI/CD)

  • Automation is often used for deployment.
    • Security gates are automated instead of manually checking.
  • Benefits:
    • Smaller increments
    • Easier detection/correction

Secure Software Disposal

  • Purpose: to safely terminate the existence of a system or a software.
    • Disposal ceases the active support of the product.
    • Secure disposal is an often-overlooked process because it involves a post-lifecycle period.
    • All stakeholders have to be constantly kept in the loop. Software can only be retired at the request of the owner.
  • Disposal is an important adjunct to security because of magnetic remanence.

Software Disposal Planning

  • Plan should define schedules, actions, and resources that:
    • terminate the delivery of software services,
    • transform the system into, or retain it in, a socially and physically acceptable state, and
    • take account of the health, safety, security, and privacy applicable to disposal actions and to the long-term condition of resulting physical material and information
  • Disposal constraints: the basis for carrying out the planned disposal activities.
  • Software Disposal Plan defines when and how support will be withdrawn and how its going to be archieved.
  • Software Disposal Strategy defines responsibilities for residual support issues and transition.
  • Stakeholders are informed of archiving methodology and accessibility to relevant records.
  • Key notes:
    • Ensure a smooth transition from the retiring system.

Software Disposal Execution

  • Aim: ensure an efficient transition into retirement.
  • Users need to be given sufficient time for the affected product.
    • Replacement
    • Date
    • Reason
    • (optional) Alternatives
  • Conduct parallel operations to ensure a smooth transition:
    • Retiring the old
    • Establishing the new
    • Train the users
    • When the time is reached, notify all stakeholders and archive the old
    • Old data may still need to be accessible according to the contract

End-of-Life Policies

  • Risk Management Guide for Information Technology Systems:
    • NIST SP 800-30, prescribes end-of-life policies
  • EOL Policy must contain:
    • Sun-setting criteria.
    • Retirement notification.
    • Support duration and sun-set grace period.
    • Recommendation and alternatives.
    • Schedule for patches and upgrades.
    • Contract renewal terms.

Sun-Setting Criteria

  • Sun-setting criteria: provide guidance as to when a particular product must be disposed or replaced.
    • End of warranty period.
    • End of product support, especially COTS.
    • End of vendor support.
    • No longer compatible with the hardware.
    • New features are available as new products, upgrades or versions releases.

Sun-setting Processes

  • Have a replacement
  • Obtain approvals
  • Update the Asset Inventory Database (AID) and Configuration Management Database (CMDB)
  • Shutdown services and adjust or remove any monitoring for old software
  • Ensure Termination Access Control (TAC)
  • Archive the software and data
  • Securely delete the software and data

Information Disposal and Media Sanitisation

  • Sanitisation: removing information from media such that recovery and disclosure is impossible.
    • Also remove classified labels, marking and activity logs.
  • Main types of storage:
    • Hardcopy or physical representation
    • Softcopy or electronic representation
  • Common means of media sanitization:
    • Disposal:
      • Discarding media without giving any considerations to sanitization
      • Technically not a type of sanitization
      • Valid for non-confidential info
    • Clearing:
      • Overwriting the media with non-sensitive random data
      • Does not guarantee the data being successfully erased (i.e. data remanence)
      • Not applicable to damaged or the Write-Once Read-Many media
    • Purging:
      • Rendering the data into an unrecoverable state
      • e.g. degaussing and executing the Secure Erase command in ATA drives
    • Destruction:
      • Ensuring that the media can no longer be reused
      • Common techniques:
        • Disintegration
        • Pulverization
        • Melting
        • Incineration or Burning
        • Shredding
  • Laboratory attack: skilled threat agents use non-standard resources and systems to perform data recovery on media outside of their normal operating settings.
  • NIST SP 800-88 Guidelines for Media Sanitisation

Examples

Misconfiguration

  • Hard coding credentials and cryptographic keys inline code or in configuration files in cleartext.
  • Not disabling the listing of directories and files in a web server.
  • Installation of software with default accounts and settings.
  • Installation of the administrative console with default configuration settings.
  • Installation or configuration of unneeded services, ports and protocols, unused pages, and unprotected files and directories.
  • Missing software patches.
  • Lack of perimeter and host defensive controls such as firewalls, filters, etc.
  • Enabling tracing and debugging can lead to attacks on confidentiality assurance. Trace information can contain security sensitive data about the internal state of the server and workflow. When debugging is enabled, errors that occur on the server side can result in presenting the entire stack trace data to the client browser.

Software hardening

  • Removal of maintenance hooks before deployment.
  • Removal of debugging code and flags in code.
  • Removing unneeded comments (dangling code) or sensitive information from comments in code.