The employer shall conduct” + “risk assessment

Posted on Apr 12, 2024 in Computers

Dependability: most important? User degree of trust in system, system will operate as expected and not fail during normal user interdep attributes: availability,reliability,security, safety, resilience, maintainability, error tolerance, repair ability Why? failures affect lots of people, unreliable = unsafe, cost, info loss, reputation causes: hardware, software, operational. Interdependent safe systems must be safe and reliable which can be hindered by cyberattacks, viruses, ddos attacks which can make system unreliable, corrupt data and affect confidence in reliability + safety costs ^ depend^- ^testing validation, technique,hardware capability. Economical: high costs, understand environment, future business/reputation, societal/political factors, law, accept lower Dep and failure costs?, depends on system environment and business needs. STS socio technical system broader systems engin process, not isolated, human/social/organizational purposes. Wildernesses weather hardware software forecasting processes, users organization, sts stack represent sociotechnical system wit interconnected lawyers 1. Equipment/hardware, 2. Operating system/high system level facilities, 3. Communication/data management/middleware facilitate remote system + databases, 4. Application systems. / sys to meet organization requirement, other layers business processes people/orgz and business activities, organization higher level strategic business activities impacting system operation, society laws regulations and culture influencing system operation. Holistics SysDes: inter + dep between layers/change in 1 affect others/regulatory changes impact business processes + apps software systems perspective for dep: essential/contains software failures within sts stack ande layers, understand how faults in layers affect software operating environment to make dependable systems.	STS stack = society/aw/regulation/culture, organizations higher level strategic business activities affecting org, business processes involving people and comp systems to support business activities, app systems = specific functionality to meet some organization requirements, communication+ data management = middleware that provides access to remote system and databases , operating system- set of common facilities for higher level in system, equipment = hardware devices which include embedded syst . Holistic system design: system interconnected wi/ layers not one entity. Change r faults in one layer affects adjacent layers, contain software failures, change in society/law regulation- affect organizational processes. Prevent failures form propitiating through entire system, holistic system design important for dependability, systems engineering approach. Safety Regulation- documentation/highcost/ certify by regulator. redundancy + diversity = process activities such as validation + verification shouldn’t depend on single approach to validate software, redundancy means diverse processes are essential for validation and verification. Redundancy and diversity = enhance dependability reliability + resilience in critical system were failures can be severe: Fault tolerance, redundancy = keep operating during failures, reliability multiple components to acheive specific function reduce failure possibility, availability enhancement- improve reliability of system if malfunction occurs, risk mitigation, use multiple varied approaches for testing and validation reduces change over overlooked issues, resilience to unexpected events – divers components make system resilient to unforeseen events or changes so system can adapt Redundancy = fault tolerance, reliability enhancement, availability boost, risk mitigation, resilience to external events eg Airbus FCS archit redun + diverse boeing 777 no software diversity. 737Max AoA x1 sensor for MFCA system should have x 2 sensor diff manufacturers.	XP – Incremental planning, small releases, simple design, test first, refactoring, pair program, colelctive ownership, continuous integration, sustainable pace, customer involve/in building, multiple version per day Security: dimensions: CIA Levels: IOA Threat types: intereption,interruption, modification, fabrication. Secure system guide: layered protect for platofrm app + record level, dsitrubte assets to minimiz impact of attacks, avoid single failure from single falws, fail securely to ensure sensitive data remains inaccessible, balance securityand usabilitym, achiee seucity w/o compromise usabiltiy, logs, redun + diver, inputformat specification, comparmentalize assets, maintain user group policies, design for deployment + recoverability, Risk mgmnt; preliminary risk assess to assessgeneric risks and decide on securitylevel, ddesign risk assessment identification and aslys high lvel system risk to determine securityrequirements, operational risk assessment, focsu on use of system and possible risks from human ehavior, Security rsk assess: asset identificaion assetto be protected, assetvalue assessment, expsure assess, threat identif, atack asses, control identification, feasability, assss to implremt controsl, securityreq def, Secure system design: security should be devsecops hard to secure later adding security feautes affects other attribues like perofrmance + usability do a design risk assessment whiel system is developet and again after deployed identify vulenrabilities from desig choice layered protect : How shoulod sys be organized so critical assets can be protected against attack, layered protection ardhitecture to provide platform level protection top level controlson the latform running system, appl level controls built in like extra password protection, record level protection when specific info is requested distribute os effects of attack are minimized and not all on one system, conflictions because if assets are distributethan more expensive to protect but if protected usability and perofrmance hindered
Redundancy- including backup components or systems designed to takeover if primary components fails, enhances reliability and availability, prevent downtime , switch to backup components, idnetical sys or comp to mitigate failures – RECOVER depend + secure more improtant than functionality because unsafe = rejected, undependable sys unreliable unsafe rejected, costs offailure high economic loss physical damage, life, info los recovery cost hig	Diversity – Incroporating variability or differences in design or implementationwithin system components to mitigate risk of ommon mode failures or if source has probloems,ensures overall robustness and fault tolerance of system, mitigate failure and prevent them PREVENT	Sec sys design guidlines: explicit securitypoliciy fundamental securityrequirement, avoid single point of failure, fail securely failure from morethan one security failure, balance security + usability, weaker securityforbetter usabilitytradeoff, log user actions, use redunancy and diversity to reduce risk, specify all system input formats, compartmentalize assets, design for development Security architct design: 1. Pportection of critical assets can use layered protection incldues platform level protection with top loevel controls on platform system runs in, app level protection specific protection mechanisms builtin to app itself eg password protect, record level protectio involved when access to specific info is requested
Attributes of dependable processes audtitable (ppl outside process check standards) diverse (diverse verification and validaton activities),documentable (outline modeling + documentation), robust(recover from failures of individual process activities), standardized (set of standards avaial) Activities: requirement review (completeness), requirement management (cotrol changes + understand impact), formal specification (create + analye math model of software) system modeling (documentgraphically), design and program inspections by diff people, static analysis on source code, test plan and management (comrpehensive sys tests) Agile + dependable processes: dependable software requires certification + documentation, up front requirements analysis import for safety securit which conflicts w/ agile, so pure agile is impractical but agile processes with additional documentation and planning can be adopted for dependable sys Cybersec: all organizational it assests from networks to app systms externallyfacing companies odnt understand details system of system type complexit Threats to integrity of assets: threatswhen system or data is damaged by cyberA result in worm or softwre corruptionto organization databases	Dependable process – Minimize system faults require verification + validation at all stages redundnacy + diversity essential for hardware + software processs and for dependable systems, sociotechnical systems computer hardware software people within organization who support business goals Formal methods – Based on mathematical representation + analaysis formal specification, analysi sand proof, transformational development + verification, verification based approaches difference representation are equivalent, refinement based appooraches systematicall turn one represent in to a lower loevel to to ensure equivalence if transformation is correct, important for reducing fault in dependable sys engin, cost effective when faults need to be avoided, specifrication and desin errors reealed through formal model analysis and inconsistencies between specification and program avoided through refinement, Formal method – Basis for development to reduce number of specification and implementation errors in system. benefits of formal specific: detailed analys if sys req, auto detect inconsistency + incomplete, transform formal specification into correct progra. Challenges = limits for pracical software, hard to understand formal sepficication, cost and benefit analsys, unfamiliarity, scalability compatabilitywith agile	4 differnce between security and safety specifications: 1. Safety probloems are accietnal not hostile envrionment realted but atackers have gained access or could based on sys weakness, 2. When safety failures occur, look for rootcause or weakness but in securitycould be purposely hidden, shuttind down system to avoid safety failrue but could be the resultof an ttadk, 4. Safty related events not generated from adversary attacker can probe defense over time to discvoer weaknesses. Security requirements classification: 1. Risk avoidance set out risks to be avoidedin sys design so risks dont happen, 2. Risk detetcftion, requirement define and identify whatto do when risks arise to neutralize the risks before loss 3. Risk mititagation requirements to set outhow sys shouldbe desigt o recoverand restor Resilience: the judgement of how well the sys can maintain continuityof its critical services in the presence of disruptive events eg equip or hardware failurs and cyber attacks. 3 resilience charactersitics: 1. Some service of system are critical and could have catastrophic causes for life, social evonomic effects. 2. Some events are distruptive and affectthe sys abilityto deliver critical services, 3. Reisilience is based on expert judgement who examine syss and operational processes. Resilience engineering: emphassis on limiting numberof system failures arising from external events like oeprator errors or cyber attacks.

Dependability:

most important? User degree of trust in system, system will operate as expected and not fail during normal user interdep attributes:
availability,reliability,security, safety, resilience, maintainability, error tolerance, repair ability

Why?

failures affect lots of people, unreliable = unsafe, cost, info loss, reputation causes:

hardware, software, operational. Interdependent safe systems must be safe and reliable which can be hindered by cyberattacks, viruses, ddos attacks which can make system unreliable, corrupt data and affect confidence in reliability + safety

costs ^ depend^- ^testing validation, technique,hardware capability.

Economical:

high costs, understand environment, future business/reputation, societal/political factors, law, accept lower Dep and failure costs?, depends on system environment and business needs.

STS socio technical system broader systems engin process, not isolated, human/social/organizational purposes. Wildernesses weather hardware software forecasting processes, users organization,

sts stack represent sociotechnical system wit interconnected lawyers 1. Equipment/hardware, 2. Operating system/high system level facilities, 3. Communication/data management/middleware facilitate remote system + databases, 4. Application systems. / sys to meet organization requirement, other layers business processes people/orgz and business activities, organization higher level strategic business activities impacting system operation, society laws regulations and culture influencing system operation.

Holistics SysDes: inter + dep between layers/change in 1 affect others/regulatory changes impact business processes + apps software

systems perspective for dep: essential/contains software failures within sts stack ande layers, understand how faults in layers affect software operating environment to make dependable systems.

STS stack = society/aw/regulation/culture, organizations higher level strategic business activities affecting org, business processes involving people and comp systems to support business activities, app systems = specific functionality to meet some organization requirements, communication+ data management = middleware that provides access to remote system and databases , operating system- set of common facilities for higher level in system, equipment = hardware devices which include embedded syst .

Holistic system design:

system interconnected wi/ layers not one entity. Change r faults in one layer affects adjacent layers, contain software failures, change in society/law regulation- affect organizational processes. Prevent failures form propitiating through entire system, holistic system design important for dependability, systems engineering approach.

Safety Regulation-

documentation/highcost/ certify by regulator.
redundancy + diversity = process activities such as validation + verification shouldn’t depend on single approach to validate software, redundancy means diverse processes are essential for validation and verification.

Redundancy and diversity = enhance dependability reliability + resilience in critical system were failures can be severe: Fault tolerance, redundancy = keep operating during failures, reliability multiple components to acheive specific function reduce failure possibility, availability enhancement- improve reliability of system if malfunction occurs, risk mitigation, use multiple varied approaches for testing and validation reduces change over overlooked issues, resilience to unexpected events – divers components make system resilient to unforeseen events or changes so system can adapt

Redundancy = fault tolerance, reliability enhancement, availability boost, risk mitigation, resilience to external events eg Airbus FCS archit redun + diverse boeing 777 no software diversity. 737Max AoA x1 sensor for MFCA system should have x 2 sensor diff manufacturers.

XP

–
Incremental planning, small releases, simple design, test first, refactoring, pair program, colelctive ownership, continuous integration, sustainable pace, customer involve/in building, multiple version per day

Security: dimensions: CIA

Levels:

IOA

Threat types:

intereption,interruption, modification, fabrication. Secure system guide: layered protect for platofrm app + record level, dsitrubte assets to minimiz impact of attacks, avoid single failure from single falws, fail securely to ensure sensitive data remains inaccessible, balance securityand usabilitym, achiee seucity w/o compromise usabiltiy, logs, redun + diver, inputformat specification, comparmentalize assets, maintain user group policies, design for deployment + recoverability,

Risk mgmnt;

preliminary risk assess to assessgeneric risks and decide on securitylevel, ddesign risk assessment identification and aslys high lvel system risk to determine securityrequirements, operational risk assessment, focsu on use of system and possible risks from human ehavior,

Security rsk assess:

asset identificaion assetto be protected, assetvalue assessment, expsure assess, threat identif, atack asses, control identification, feasability, assss to implremt controsl, securityreq def,

Secure system design:

security should be devsecops hard to secure later adding security feautes affects other attribues like perofrmance + usability

do a design risk assessment whiel system is developet and again after deployed identify vulenrabilities from desig choice

layered protect
:
How shoulod sys be organized so critical assets can be protected against attack, layered protection ardhitecture to provide platform level protection top level controlson the latform running system, appl level controls built in like extra password protection, record level protection when specific info is requested

distribute os effects of attack are minimized and not all on one system, conflictions because if assets are distributethan more expensive to protect but if protected usability and perofrmance hindered

Redundancy-

including backup components or systems designed to takeover if primary components fails, enhances reliability and availability, prevent downtime , switch to backup components, idnetical sys or comp to mitigate failures –

RECOVER

depend + secure more improtant than functionality because unsafe = rejected, undependable sys unreliable unsafe rejected, costs offailure high economic loss physical damage, life, info los recovery cost hig

Diversity

–
Incroporating variability or differences in design or implementationwithin system components to mitigate risk of ommon mode failures or if source has probloems,ensures overall robustness and fault tolerance of system, mitigate failure and prevent them PREVENT

Sec sys design guidlines:

explicit securitypoliciy fundamental securityrequirement, avoid single point of failure, fail securely failure from morethan one security failure, balance security + usability, weaker securityforbetter usabilitytradeoff, log user actions, use redunancy and diversity to reduce risk, specify all system input formats, compartmentalize assets, design for development

Security architct design:

1. Pportection of critical assets can use layered protection incldues platform level protection with top loevel controls on platform system runs in, app level protection specific protection mechanisms builtin to app itself eg password protect, record level protectio involved when access to specific info is requested

OtSUBERERERkRtHXb9EREREROTGUVAREREREZEbR0FFRERERERuHAUVERERERG5cRRURERERETkxlFQERERERGRG0dBRUREREREbhwFFRERERERuXEUVERERERE5MZRUBERERERkRtHQUVERERERG4cBRUREREREblxFFREREREROTGUVAREREREZEbR0FFRERERERuHAUVERERERG5cRRURERERETkxlFQERERERGRG0dBRUREREREbhwFFRERERERuXH+H9bT8anP12PDAAAAAElFTkSuQmCC

Attributes of dependable processes

audtitable (ppl outside process check standards) diverse (diverse verification and validaton activities),documentable (outline modeling + documentation), robust(recover from failures of individual process activities), standardized (set of standards avaial)

Activities:

requirement review (completeness), requirement management (cotrol changes + understand impact), formal specification (create + analye math model of software) system modeling (documentgraphically), design and program inspections by diff people, static analysis on source code, test plan and management (comrpehensive sys tests)

Agile + dependable processes:

dependable software requires certification + documentation, up front requirements analysis import for safety securit which conflicts w/ agile, so pure agile is impractical but agile processes with additional documentation and planning can be adopted for dependable sys

Cybersec:

all organizational it assests from networks to app systms externallyfacing companies odnt understand details system of system type complexit

Threats to integrity of assets:

threatswhen system or data is damaged by cyberA result in worm or softwre corruptionto organization databases

Dependable process

–
Minimize system faults require verification + validation at all stages

redundnacy + diversity essential for hardware + software processs and for dependable systems, sociotechnical systems computer hardware software people within organization who support business goals

Formal methods

–
Based on mathematical representation + analaysis formal specification, analysi sand proof, transformational development + verification, verification based approaches difference representation are equivalent, refinement based appooraches systematicall turn one represent in to a lower loevel to to ensure equivalence if transformation is correct, important for reducing fault in dependable sys engin, cost effective when faults need to be avoided, specifrication and desin errors reealed through formal model analysis and inconsistencies between specification and program avoided through refinement,

Formal method

–
Basis for development to reduce number of specification and implementation errors in system.

benefits of formal specific: detailed analys if sys req, auto detect inconsistency + incomplete, transform formal specification into correct progra.
Challenges = limits for pracical software, hard to understand formal sepficication, cost and benefit analsys, unfamiliarity, scalability compatabilitywith agile

4 differnce between security and safety specifications:

1. Safety probloems are accietnal not hostile envrionment realted but atackers have gained access or could based on sys weakness, 2. When safety failures occur, look for rootcause or weakness but in securitycould be purposely hidden, shuttind down system to avoid safety failrue but could be the resultof an ttadk, 4. Safty related events not generated from adversary attacker can probe defense over time to discvoer weaknesses.

Security requirements classification:

1. Risk avoidance set out risks to be avoidedin sys design so risks dont happen, 2. Risk detetcftion, requirement define and identify whatto do when risks arise to neutralize the risks before loss 3. Risk mititagation requirements to set outhow sys shouldbe desigt o recoverand restor

Resilience:

the judgement of how well the sys can maintain continuityof its critical services in the presence of disruptive events eg equip or hardware failurs and cyber attacks.

3 resilience charactersitics:

1. Some service of system are critical and could have catastrophic causes for life, social evonomic effects. 2. Some events are distruptive and affectthe sys abilityto deliver critical services, 3. Reisilience is based on expert judgement who examine syss and operational processes.

Resilience engineering:

emphassis on limiting numberof system failures arising from external events like oeprator errors or cyber attacks.

Cybercontrols for threats:

authentication, encryption, firewalls

4 Rs of resilience engineering recognition resistnace, recovery and reinstatement

Key stages in cyberresiliency plnning:

asset classification, threat identificaiton, threat recognition, identify how ca attack or threat can be recognized, threat resistance, asset recovery, ass4etresinstament define procedures to get service back up and running in normal operation

resilience planning = sociotechnical rather than technical activities influenced by cultural polcieis and procedures of organization that own and use software systems

Human errors:

1.
person approach to viewing human errors individual unsafe acts operator failing to engage safety feature or careless ness or recklessness, 2.
system approach assumes people are fallible and make mistakes under pressure high workloads, inappropriate sys design avoid recurrence understand system defences

Resilience system design:

identify critical services and assets, 2. Design components to support problem recognition eg watch dog timer, recognition, resistance, and redcovery and reinstatement

Survivability analysis stages:

1. System understanding – goals, missions object, requirements , arch, 2. Critical service identification, services to be maintained and necessary components, 3. Attack simulation: use cases for possible attacks and system components affected, 4. Survivability analysis: identify compromisable compnents and implement survivability strategies based on the 4r’s

problem: starting points is the requirements and arhcitec design of system diffuclt for business systems because not related to business requirements and there has to be detailed requirements

Strategies to increase system resilience:

Reduce the probability of the occurrence of an external event that might trigger system failures.
• Increase the number of defensive layers. The more layers that you have in a system, the less likelyit is that the holes will line up and a system failure occur. Design a system so that diverse types of barriers are included. The ‘holes’ will probably be indifferent places and so there is less chance of the holes lining up and failing to trap an error.Minimize the number of latent conditions in a system. This means reducing the number and size of system ‘holes’.

Security assurance

Vulnerability avoidance
◦ The system is designed so that vulnerabilities do not occur. For example, if there is no external network
connection then external attack is impossible
• Attack detection and elimination
◦ The system is designed so that attacks on vulnerabilities are detected and neutralized before they result in
an exposure. For example, virus checkers find and remove viruses before they infect a system
• Exposure limitation and recovery
◦ The system is designed so that the adverse consequences of a successful attack are minimized. For
example, a backup policy allows damaged information to be restored

Reuse;

using existing components used in other system systemic software reused reused based development• System reuse
◦ Complete systems, which may include several application programs may be reused.
• Application reuse
◦ An application may be reused either by incorporating it without change into other or by developing
application families.
• Component reuse Components of an application from sub-systems to single objects may be reused.Object and function reuse
◦ Small-scale software components that implement a single well-defined object or function may be reused.

benefits- faster development, 2. Effective use of specialist, 3. Increased dependability, 4 lower delop cots, reduced process risk, standards compliance

disadvantages of software reuse:1. Difficulty maintaining library of components, finding understanding and adopting the components, increased maintenance cost and time.

reuse problems: 1. Lackof tool supporthard to integrate with component library syste tools dont take reuse into account true for embedded systems, 2. Note invented here syndrome – some software eng wantto improve them and write original software

reusable app frameworks – integrate sets of software artefacts that contain objects classes and components that collaborate to provide reusable familyof related applications, large entities, sub system design collection of abstract class and the interface btween them –> vue.Js, lravel phph, react java sript, asp,net for cloud in C#, can be extented

web app frameworks – support front end web apps java python rub interaction model based on model view controller composite patter,

model view controller: system infrstructue for GUI design, alloow for multiple presentations of object separate interactions with presentation, involve instantiating patterns good for security auth pages, dynamic, database support, session management, userinteraction

types of frameworks -1. System infrastructure – eg communication userinterface compilers, middleware integration frameworkstandards and calsses componentcommunication and info exchange, enterprise app fraemwork for telecomm and financial sys

Redundancy for cyber resilience:

each system should have copies of data and software on separate backup system, avoid shared disks to support recovery and reinstatement. 2. Multistage diverse authentication to protect pwords and auth multifactor, token key pas or code, 3. Critical servers can be over provisioned and more powerful than required so shared capacity so use spare capacity to resist attacks without degrading service, use spare capacity to run software during repair fore resistance and recovery

Hollnagel organizational resilience:

ability to respond (adapt processes and procedures in response to risks), 2. Ability to monitor ( monitor internal operations and external environment before threats happen, employee securitypolicies), 3. Ability to anticipate (anticipate possible threats and changes that may affect operations or resilience, 4. Ability to learn (learn from experience like successful responses to adverse events effective resistance to attack

Resilience engineering with poor requirements for business software:

identify resilience requirements, plan system reinstatate and integrate with normal backup, identify system failures and potential cyberattacks to design recognition and resilience strategies, plan system and service reocvery strategies, testall aspects of resilience planning to identify failures and scenarios.

4 R’s:

The system or its operators should recognize early indications of system failure.
• If the symptoms of a problem or cyberattack are detected early, then resistance strategies may be
used to reduce the probability that the system will fail.
• If a failure occurs, the recovery activity ensures that critical system services are restored quickly so
that system users are not badly affected by failure.
• In this final activity, all of the system services are restored and normal system operation can continue.

types of security requirements:

Identification requirements.
• Authentication requirements.
• Authorization requirements.
• Immunity requirements.
• Integrity requirements.
• Intrusion detection requirements.
• Non-repudiation requirements.
• Privacy requirements.
• Security auditing requirements.
• System maintenance security requirements.

Approaches to software reuse:

1. App frameworks- collections of abstract + concrete classes adopted and extended to create application systems, 2 or more apps systems integrated to provide extended function, 3. Architectural patterns standard soft arch support common app types and are the basis of applications, 3. Aspect oriented software develop when shared components are woven into application at diff places when program is compiled, component based software engineering – system developed by integrating compontns eg collections of objects to conform to component model standards

factors to consider when incorporating reuse: 1. Development schedule, 2, expetcted software lifetime, background/skills team, critical nature of software, 5, non functional requirement, 6, application domain, 7 execution platform

software product lines: app familes with generic functionalitythat can be adapted and configured for use in specific context, software product line = setof of apps with common archit and shared components eahc with apps specialized to reflectdiff requirements

Defense in depth approach:

1. Conflict alert warning part of air traffic control system, formalized recording procedures setting out how to record control instructions issued to aircraft, collaborative checking by team of controllers who monitor each others work,

Maintaining critical service availability requires the following knowledge:

– business critical system services, minimal quality of services to be maintained, how service can be compromised, how they can be protected, how they can be recovered

eg. Info system of patients current diagnosis and treatment pan, warning services for high risk patients, eg patient record database, databse server, network for client/server, laptop, setof rules for patients that need to be floagged in their records

adverse events: unavaialbity of database server through system or network failures or ddos, corruption of records, malware, infection, in client or host, unauthorized access

plan for server: watchdog timer recognition and resistance of system architect top maintain local copies of critical info

Approaches supporting software reuse:

Configurable Application Systems: Customize software for specific users; e.G., tailoring a project management tool to suit the unique needs of a research team.

Design Patterns: Utilize standardized solutions to common problems; e.G., implementing the Singleton pattern for managing a single instance of a database connection.

ERP Systems: Adapt large-scale systems to business requirements; e.G., configuring an ERP system to handle payroll, accounting, and inventory for a manufacturing company.

Legacy System Wrapping: Integrate older systems with modern interfaces; e.G., wrapping a COBOL-based inventory system with APIs for seamless interaction with a new web-based front end.

Model-Driven Engineering: Generate code from abstract models; e.G., creating database tables and application logic based on a high-level data model for an e-commerce platform.