This document provides an overview of topics in chapter 13 on security engineering. It discusses security and dependability, security dimensions of confidentiality, integrity and availability. It also outlines different security levels including infrastructure, application and operational security. Key aspects of security engineering are discussed such as secure system design, security testing and assurance. Security terminology and examples are provided. The relationship between security and dependability factors like reliability, availability, safety and resilience is examined. The document also covers security in organizations and the role of security policies.
Covers security and privacy issues for software product developers including attacks and defenses, encryption, authentication, authorisation and data protection
Covers security and privacy issues for software product developers including attacks and defenses, encryption, authentication, authorisation and data protection
Modification data attack inside computer systems: A critical reviewCSITiaesprime
Â
This paper is a review of types of modification data attack based on computer systems and it explores the vulnerabilities and mitigations. Altering information is a kind of cyber-attack during which intruders interfere, catch, alter, take, or erase critical data on the personal computers (PCs) and applications through using network exploit or by running malicious executable codes on victim's system. One of the most difficult and trendy areas in information security is to protect the sensitive information and secure devices from any kind of threats. Latest advancements in information technology in the field of information security reveal huge amount of budget funded for and spent on developing and addressing security threats to mitigate them. This helps in a variety of settings such as military, business, science, and entertainment. Considering all concerns, the security issues almost always come at first as the most critical concerns in the modern time. As a matter of fact, there is no ultimate security solution; although recent developments in security analysis are finding daily vulnerabilities, there are many motivations to spend billions of dollars to ensure there are vulnerabilities waiting for any kind of breach or exploit to penetrate into the systems and networks and achieve particular interests. In terms of modifying data and information, from old-fashioned attacks to recent cyber ones, all of the attacks are using the same signature: either controlling data streams to easily breach system protections or using non-control-data attack approaches. Both methods can damage applications which work on decision-making data, user input data, configuration data, or user identity data to a large extent. In this review paper, we have tried to express trends of vulnerabilities in the network protocolsâ applications.
Describe two methods for communicating the material in an Informatio.pdfarchgeetsenterprises
Â
Describe two methods for communicating the material in an Information Security policy to the
staff of an organization. What are the strengths and weaknesses of each?
Solution
Information security means protecting information (data) and information systems from
unauthorized access, use, disclosure, disruption, modification, or destruction.
Information Security management is a process of defining the security controls in order to
protect the information assets.
Security Program
The first action of a management program to implement information security is to have a
security program in place. Though some argue the first act would be to gain some real \"proof of
concept\" and \"explainable thru display on the monitor screen\" security knowledge. Start with
maybe understanding where OS passwords are stored within the code inside a file within a
directory. If you don\'t understand Operating Systems at the root directory level maybe you
should seek out advice from somebody who does before even beginning to implement security
program management and objectives.
Security Program Objectives
¡ Protect the company and its assets.
¡ Manage Risks by Identifying assets, discovering threats and estimating the risk
¡ Provide direction for security activities by framing of information security policies,
procedures, standards, guidelines and baselines
¡ Information Classification
¡ Security Organization and
¡ Security Education
Security Management Responsibilities
¡ Determining objectives, scope, policies,re expected to be accomplished from a security
program
¡ Evaluate business objectives, security risks, user productivity, and functionality
requirements.
¡ Define steps to ensure that all the above are accounted for and properly addressed
Approaches to Build a Security Program
¡ Top-Down Approach
¡ The initiation, support, and direction comes from the top management and work their way
through middle management and then to staff members.
¡ Treated as the best approach but seems to based on the I get paid more therefor I must
know more about everything type of mentality.
¡ Ensures that the senior management who are ultimately responsible for protecting the
company assets is driving the program.
¡ Bottom-Up Approach
¡ The lower-end team comes up with a security control or a program without proper
management support and direction.
¡ It is oft considered less effective and doomed to fail for the same flaw in thinking as
above; I get paid more therefor I must know more about everything.
Since advancement is directly tied to how well you can convince others, who often fall outside of
your of job duties and department, as to your higher value to the company as stated by your own
effective written communication this leads to amazing resume writers and take no blame style of
email responses that seems to definitely lead to the eventual failure of company\'s standards and
actual knowledge. It is often covered up by relationships which form at the power levels within
any gr.
FellowBuddy.com is an innovative platform that brings students together to share notes, exam papers, study guides, project reports and presentation for upcoming exams.
We connect Students who have an understanding of course material with Students who need help.
Benefits:-
# Students can catch up on notes they missed because of an absence.
# Underachievers can find peer developed notes that break down lecture and study material in a way that they can understand
# Students can earn better grades, save time and study effectively
Our Vision & Mission â Simplifying Students Life
Our Belief â âThe great breakthrough in your life comes when you realize it, that you can learn anything you need to learn; to accomplish any goal that you have set for yourself. This means there are no limits on what you can be, have or do.â
Like Us - https://www.facebook.com/FellowBuddycom
New Developments in Cybersecurity and Technology for RDOs: Howlandnado-web
Â
This presentation was delivered at NADO's 2018 Annual Training Conference, held in Charlotte, NC on October 13-16. For more information, visit: https://www.nado.org/events/2018-annual-training-conference/
Discusses the microservices architectural style for cloud-based systems. Explains what is meant by microservices and architectural choices for microservices
Introduces some fundamentals of cloud based software and discusses architectural issues for product developers. Covers containers, databases and cloud architecture choices
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Â
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Â
Are you looking to streamline your workflows and boost your projectsâ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, youâre in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part âEssentials of Automationâ series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Hereâs what youâll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
Weâll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Donât miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Â
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Â
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Dev Dives: Train smarter, not harder â active learning and UiPath LLMs for do...UiPathCommunity
Â
đĨ Speed, accuracy, and scaling â discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Miningâĸ:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing â with little to no training required
Get an exclusive demo of the new family of UiPath LLMs â GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
đ¨âđĢ Andras Palfi, Senior Product Manager, UiPath
đŠâđĢ Lenka Dulovicova, Product Program Manager, UiPath
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Â
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But thereâs more:
In a second workflow supporting the same use case, youâll see:
Your campaign sent to target colleagues for approval
If the âApproveâ button is clicked, a Jira/Zendesk ticket is created for the marketing design team
Butâif the âRejectâ button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
Â
As AI technology is pushing into IT I was wondering myself, as an âinfrastructure container kubernetes guyâ, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefitâs both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
Â
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. Whatâs changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Â
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Â
Clients donât know what they donât know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clientsâ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Â
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Â
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
2. Topics covered
ī˛ Security and dependability
ī˛ Security and organizations
ī˛ Security requirements
ī˛ Secure systems design
ī˛ Security testing and assurance
Chapter 13 Security Engineering 212/11/2014
3. Security engineering
ī˛ Tools, techniques and methods to support the
development and maintenance of systems that can resist
malicious attacks that are intended to damage a
computer-based system or its data.
ī˛ A sub-field of the broader field of computer security.
Chapter 13 Security Engineering 312/11/2014
4. Security dimensions
ī˛ Confidentiality
ī§ Information in a system may be disclosed or made accessible to
people or programs that are not authorized to have access to
that information.
ī˛ Integrity
ī§ Information in a system may be damaged or corrupted making it
unusual or unreliable.
ī˛ Availability
ī§ Access to a system or its data that is normally available may not
be possible.
12/11/2014 Chapter 13 Security Engineering 4
5. Security levels
ī˛ Infrastructure security, which is concerned with
maintaining the security of all systems and networks that
provide an infrastructure and a set of shared services to
the organization.
ī˛ Application security, which is concerned with the security
of individual application systems or related groups of
systems.
ī˛ Operational security, which is concerned with the secure
operation and use of the organizationâs systems.
12/11/2014 Chapter 13 Security Engineering 5
6. System layers where security may be
compromised
Chapter 13 Security Engineering 612/11/2014
7. Application/infrastructure security
ī˛ Application security is a software engineering problem
where the system is designed to resist attacks.
ī˛ Infrastructure security is a systems management
problem where the infrastructure is configured to resist
attacks.
ī˛ The focus of this chapter is application security rather
than infrastructure security.
Chapter 13 Security Engineering 712/11/2014
8. System security management
ī˛ User and permission management
ī§ Adding and removing users from the system and setting up
appropriate permissions for users
ī˛ Software deployment and maintenance
ī§ Installing application software and middleware and configuring
these systems so that vulnerabilities are avoided.
ī˛ Attack monitoring, detection and recovery
ī§ Monitoring the system for unauthorized access, design
strategies for resisting attacks and develop backup and recovery
strategies.
Chapter 13 Security Engineering 812/11/2014
9. Operational security
ī˛ Primarily a human and social issue
ī˛ Concerned with ensuring the people do not take actions
that may compromise system security
ī§ E.g. Tell others passwords, leave computers logged on
ī˛ Users sometimes take insecure actions to make it easier
for them to do their jobs
ī˛ There is therefore a trade-off between system security
and system effectiveness.
12/11/2014 Chapter 13 Security Engineering 9
11. Security
ī˛ The security of a system is a system property that
reflects the systemâs ability to protect itself from
accidental or deliberate external attack.
ī˛ Security is essential as most systems are networked so
that external access to the system through the Internet is
possible.
ī˛ Security is an essential pre-requisite for availability,
reliability and safety.
11Chapter 13 Security Engineering12/11/2014
12. Fundamental security
ī˛ If a system is a networked system and is insecure then
statements about its reliability and its safety are
unreliable.
ī˛ These statements depend on the executing system and
the developed system being the same. However,
intrusion can change the executing system and/or its
data.
ī˛ Therefore, the reliability and safety assurance is no
longer valid.
12Chapter 13 Security Engineering12/11/2014
13. Security terminology
Term Definition
Asset Something of value which has to be protected. The asset may be the software
system itself or data used by that system.
Attack An exploitation of a systemâs vulnerability. Generally, this is from outside the
system and is a deliberate attempt to cause some damage.
Control A protective measure that reduces a systemâs vulnerability. Encryption is an
example of a control that reduces a vulnerability of a weak access control
system
Exposure Possible loss or harm to a computing system. This can be loss or damage to
data, or can be a loss of time and effort if recovery is necessary after a security
breach.
Threat Circumstances that have potential to cause loss or harm. You can think of these
as a system vulnerability that is subjected to an attack.
Vulnerability A weakness in a computer-based system that may be exploited to cause loss or
harm.
13Chapter 13 Security Engineering12/11/2014
14. Examples of security terminology (Mentcare)
Term Example
Asset The records of each patient that is receiving or has received treatment.
Exposure Potential financial loss from future patients who do not seek treatment
because they do not trust the clinic to maintain their data. Financial loss
from legal action by the sports star. Loss of reputation.
Vulnerability A weak password system which makes it easy for users to set
guessable passwords. User ids that are the same as names.
Attack An impersonation of an authorized user.
Threat An unauthorized user will gain access to the system by guessing the
credentials (login name and password) of an authorized user.
Control A password checking system that disallows user passwords that are
proper names or words that are normally included in a dictionary.
14Chapter 13 Security Engineering12/11/2014
15. Threat types
ī˛ Interception threats that allow an attacker to gain access
to an asset.
ī§ A possible threat to the Mentcare system might be a situation
where an attacker gains access to the records of an individual
patient.
ī˛ Interruption threats that allow an attacker to make part of
the system unavailable.
ī§ A possible threat might be a denial of service attack on a system
database server so that database connections become
impossible.
Chapter 13 Security Engineering 1512/11/2014
16. Threat types
ī˛ Modification threats that allow an attacker to tamper with
a system asset.
ī§ In the Mentcare system, a modification threat would be where an
attacker alters or destroys a patient record.
ī˛ Fabrication threats that allow an attacker to insert false
information into a system.
ī§ This is perhaps not a credible threat in the Mentcare system but
would be a threat in a banking system, where false transactions
might be added to the system that transfer money to the
perpetratorâs bank account.
12/11/2014 Chapter 13 Security Engineering 16
17. 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 neutralised 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 minimised. For example, a backup policy
allows damaged information to be restored
17Chapter 13 Security Engineering12/11/2014
18. Security and dependability
ī˛ Security and reliability
ī§ If a system is attacked and the system or its data are corrupted
as a consequence of that attack, then this may induce system
failures that compromise the reliability of the system.
ī˛ Security and availability
ī§ A common attack on a web-based system is a denial of service
attack, where a web server is flooded with service requests from
a range of different sources. The aim of this attack is to make the
system unavailable.
12/11/2014 Chapter 13 Security Engineering 18
19. Security and dependability
ī˛ Security and safety
ī§ An attack that corrupts the system or its data means that
assumptions about safety may not hold. Safety checks rely on
analysing the source code of safety critical software and assume
the executing code is a completely accurate translation of that
source code. If this is not the case, safety-related failures may be
induced and the safety case made for the software is invalid.
ī˛ Security and resilience
ī§ Resilience is a system characteristic that reflects its ability to
resist and recover from damaging events. The most probable
damaging event on networked software systems is a cyberattack
of some kind so most of the work now done in resilience is
aimed at deterring, detecting and recovering from such attacks.
12/11/2014 Chapter 13 Security Engineering 19
21. Security is a business issue
ī˛ Security is expensive and it is important that security
decisions are made in a cost-effective way
ī§ There is no point in spending more than the value of an asset to
keep that asset secure.
ī˛ Organizations use a risk-based approach to support
security decision making and should have a defined
security policy based on security risk analysis
ī˛ Security risk analysis is a business rather than a
technical process
12/11/2014 Chapter 13 Security Engineering 21
22. Organizational security policies
ī˛ Security policies should set out general information
access strategies that should apply across the
organization.
ī˛ The point of security policies is to inform everyone in an
organization about security so these should not be long
and detailed technical documents.
ī˛ From a security engineering perspective, the security
policy defines, in broad terms, the security goals of the
organization.
ī˛ The security engineering process is concerned with
implementing these goals.
12/11/2014 Chapter 13 Security Engineering 22
23. Security policies
ī˛ The assets that must be protected
ī§ It is not cost-effective to apply stringent security procedures to all
organizational assets. Many assets are not confidential and can
be made freely available.
ī˛ The level of protection that is required for different types
of asset
ī§ For sensitive personal information, a high level of security is
required; for other information, the consequences of loss may be
minor so a lower level of security is adequate.
12/11/2014 Chapter 13 Security Engineering 23
24. Security policies
ī˛ The responsibilities of individual users, managers and
the organization
ī§ The security policy should set out what is expected of users e.g.
strong passwords, log out of computers, office security, etc.
ī˛ Existing security procedures and technologies that
should be maintained
ī§ For reasons of practicality and cost, it may be essential to
continue to use existing approaches to security even where
these have known limitations.
12/11/2014 Chapter 13 Security Engineering 24
25. Security risk assessment and management
ī˛ Risk assessment and management is concerned with
assessing the possible losses that might ensue from
attacks on the system and balancing these losses
against the costs of security procedures that may reduce
these losses.
ī˛ Risk management should be driven by an organisational
security policy.
ī˛ Risk management involves
ī§ Preliminary risk assessment
ī§ Life cycle risk assessment
ī§ Operational risk assessment
Chapter 13 Security Engineering 2512/11/2014
26. Preliminary risk assessment
ī˛ The aim of this initial risk assessment is to identify
generic risks that are applicable to the system and to
decide if an adequate level of security can be achieved
at a reasonable cost.
ī˛ The risk assessment should focus on the identification
and analysis of high-level risks to the system.
ī˛ The outcomes of the risk assessment process are used
to help identify security requirements.
12/11/2014 Chapter 13 Security Engineering 26
27. Design risk assessment
ī˛ This risk assessment takes place during the system
development life cycle and is informed by the technical
system design and implementation decisions.
ī˛ The results of the assessment may lead to changes to
the security requirements and the addition of new
requirements.
ī˛ Known and potential vulnerabilities are identified, and
this knowledge is used to inform decision making about
the system functionality and how it is to be implemented,
tested, and deployed.
12/11/2014 Chapter 13 Security Engineering 27
28. Operational risk assessment
ī˛ This risk assessment process focuses on the use of the
system and the possible risks that can arise from human
behavior.
ī˛ Operational risk assessment should continue after a
system has been installed to take account of how the
system is used.
ī˛ Organizational changes may mean that the system is
used in different ways from those originally planned.
These changes lead to new security requirements that
have to be implemented as the system evolves.
12/11/2014 Chapter 13 Security Engineering 28
30. Security specification
ī˛ Security specification has something in common with safety
requirements specification â in both cases, your concern is to avoid
something bad happening.
ī˛ Four major differences
ī§ Safety problems are accidental â the software is not operating in a
hostile environment. In security, you must assume that attackers have
knowledge of system weaknesses
ī§ When safety failures occur, you can look for the root cause or weakness
that led to the failure. When failure results from a deliberate attack, the
attacker may conceal the cause of the failure.
ī§ Shutting down a system can avoid a safety-related failure. Causing a
shut down may be the aim of an attack.
ī§ Safety-related events are not generated from an intelligent adversary.
An attacker can probe defenses over time to discover weaknesses.
30Chapter 13 Security Engineering12/11/2014
32. Security requirement classification
ī˛ Risk avoidance requirements set out the risks that
should be avoided by designing the system so that these
risks simply cannot arise.
ī˛ Risk detection requirements define mechanisms that
identify the risk if it arises and neutralise the risk before
losses occur.
ī˛ Risk mitigation requirements set out how the system
should be designed so that it can recover from and
restore system assets after some loss has occurred.
12/11/2014 Chapter 13 Security Engineering 32
33. The preliminary risk assessment process for
security requirements
33Chapter 13 Security Engineering12/11/2014
34. Security risk assessment
ī˛ Asset identification
ī§ Identify the key system assets (or services) that have to be
protected.
ī˛ Asset value assessment
ī§ Estimate the value of the identified assets.
ī˛ Exposure assessment
ī§ Assess the potential losses associated with each asset.
ī˛ Threat identification
ī§ Identify the most probable threats to the system assets
34Chapter 13 Security Engineering12/11/2014
35. Security risk assessment
ī˛ Attack assessment
ī§ Decompose threats into possible attacks on the system and the
ways that these may occur.
ī˛ Control identification
ī§ Propose the controls that may be put in place to protect an
asset.
ī˛ Feasibility assessment
ī§ Assess the technical feasibility and cost of the controls.
ī˛ Security requirements definition
ī§ Define system security requirements. These can be
infrastructure or application system requirements.
35Chapter 13 Security Engineering12/11/2014
36. Asset analysis in a preliminary risk assessment
report for the Mentcare system
Asset Value Exposure
The information system High. Required to support all
clinical consultations. Potentially
safety-critical.
High. Financial loss as clinics
may have to be canceled. Costs
of restoring system. Possible
patient harm if treatment cannot
be prescribed.
The patient database High. Required to support all
clinical consultations. Potentially
safety-critical.
High. Financial loss as clinics
may have to be canceled. Costs
of restoring system. Possible
patient harm if treatment cannot
be prescribed.
An individual patient record Normally low although may be
high for specific high-profile
patients.
Low direct losses but possible
loss of reputation.
36Chapter 13 Security Engineering12/11/2014
37. Threat and control analysis in a preliminary risk
assessment report
Threat Probability Control Feasibility
An unauthorized user
gains access as
system manager and
makes system
unavailable
Low Only allow system
management from
specific locations that are
physically secure.
Low cost of implementation but
care must be taken with key
distribution and to ensure that
keys are available in the event
of an emergency.
An unauthorized user
gains access as
system user and
accesses confidential
information
High Require all users to
authenticate themselves
using a biometric
mechanism.
Log all changes to
patient information to
track system usage.
Technically feasible but high-
cost solution. Possible user
resistance.
Simple and transparent to
implement and also supports
recovery.
37Chapter 13 Security Engineering12/11/2014
38. Security requirements for the Mentcare system
ī˛ Patient information shall be downloaded at the start of a
clinic session to a secure area on the system client that
is used by clinical staff.
ī˛ All patient information on the system client shall be
encrypted.
ī˛ Patient information shall be uploaded to the database
after a clinic session has finished and deleted from the
client computer.
ī˛ A log on a separate computer from the database server
must be maintained of all changes made to the system
database.
38Chapter 13 Security Engineering12/11/2014
39. Misuse cases
ī˛ Misuse cases are instances of threats to a system
ī˛ Interception threats
ī§ Attacker gains access to an asset
ī˛ Interruption threats
ī§ Attacker makes part of a system unavailable
ī˛ Modification threats
ī§ A system asset if tampered with
ī˛ Fabrication threats
ī§ False information is added to a system
Chapter 13 Security Engineering 3912/11/2014
41. Mentcare use case â Transfer data
12/11/2014 Chapter 13 Security Engineering 41
Mentcare system: Transfer data
Actors Medical receptionist, Patient records system (PRS)
Description A receptionist may transfer data from the Mentcare system to a
general patient record database that is maintained by a health
authority. The information transferred may either be updated
personal information (address, phone number, etc.) or a
summary of the patientâs diagnosis and treatment.
Data Patientâs personal information, treatment summary.
Stimulus User command issued by medical receptionist.
Response Confirmation that PRS has been updated.
Comments The receptionist must have appropriate security permissions to
access the patient information and the PRS.
42. Mentcare misuse case: Intercept transfer
Mentcare system: Intercept transfer (Misuse case)
Actors Medical receptionist, Patient records system (PRS), Attacker
Description A receptionist transfers data from his or her PC to the Mentcare
system on the server. An attacker intercepts the data transfer and
takes a copy of that data.
Data
(assets)
Patientâs personal information, treatment summary
Attacks A network monitor is added to the system and packets from the
receptionist to the server are intercepted.
A spoof server is set up between the receptionist and the
database server so that receptionist believes they are interacting
with the real system.
12/11/2014 Chapter 13 Security Engineering 42
43. Misuse case: Intercept transfer
12/11/2014 Chapter 13 Security Engineering 43
Mentcare system: Intercept transfer (Misuse case)
Mitigations All networking equipment must be maintained in a locked
room. Engineers accessing the equipment must be
accredited.
All data transfers between the client and server must be
encrypted.
Certificate-based client-server communication must be
used
Requirements All communications between the client and the server
must use the Secure Socket Layer (SSL). The https
protocol uses certificate based authentication and
encryption.
45. Secure systems design
ī˛ Security should be designed into a system â it is very
difficult to make an insecure system secure after it has
been designed or implemented
ī˛ Architectural design
ī§ how do architectural design decisions affect the security of a
system?
ī˛ Good practice
ī§ what is accepted good practice when designing secure systems?
Chapter 13 Security Engineering 4512/11/2014
46. Design compromises
ī˛ Adding security features to a system to enhance its
security affects other attributes of the system
ī˛ Performance
ī§ Additional security checks slow down a system so its response
time or throughput may be affected
ī˛ Usability
ī§ Security measures may require users to remember information
or require additional interactions to complete a transaction. This
makes the system less usable and can frustrate system users.
12/11/2014 Chapter 13 Security Engineering 46
47. Design risk assessment
ī˛ Risk assessment while the system is being developed
and after it has been deployed
ī˛ More information is available - system platform,
middleware and the system architecture and data
organisation.
ī˛ Vulnerabilities that arise from design choices may
therefore be identified.
Chapter 13 Security Engineering 4712/11/2014
48. Design and risk assessment
Chapter 13 Security Engineering 4812/11/2014
49. Protection requirements
ī˛ Protection requirements may be generated when
knowledge of information representation and system
distribution
ī˛ Separating patient and treatment information limits the
amount of information (personal patient data) that needs
to be protected
ī˛ Maintaining copies of records on a local client protects
against denial of service attacks on the server
ī§ But these may need to be encrypted
12/11/2014 Chapter 13 Security Engineering 49
51. Design decisions from use of COTS
ī˛ System users authenticated using a name/password
combination.
ī˛ The system architecture is client-server with clients
accessing the system through a standard web browser.
ī˛ Information is presented as an editable web form.
Chapter 13 Security Engineering 5112/11/2014
53. Security requirements
ī˛ A password checker shall be made available and shall
be run daily. Weak passwords shall be reported to
system administrators.
ī˛ Access to the system shall only be allowed by approved
client computers.
ī˛ All client computers shall have a single, approved web
browser installed by system administrators.
Chapter 13 Security Engineering 5312/11/2014
54. Architectural design
ī˛ Two fundamental issues have to be considered when
designing an architecture for security.
ī§ Protection
âĸ How should the system be organised so that critical assets can be
protected against external attack?
ī§ Distribution
âĸ How should system assets be distributed so that the effects of a
successful attack are minimized?
ī˛ These are potentially conflicting
ī§ If assets are distributed, then they are more expensive to protect.
If assets are protected, then usability and performance
requirements may be compromised.
Chapter 13 Security Engineering 5412/11/2014
55. Protection
ī˛ Platform-level protection
ī§ Top-level controls on the platform on which a system runs.
ī˛ Application-level protection
ī§ Specific protection mechanisms built into the application itself
e.g. additional password protection.
ī˛ Record-level protection
ī§ Protection that is invoked when access to specific information is
requested
ī˛ These lead to a layered protection architecture
Chapter 13 Security Engineering 5512/11/2014
57. Distribution
ī˛ Distributing assets means that attacks on one system do
not necessarily lead to complete loss of system service
ī˛ Each platform has separate protection features and may
be different from other platforms so that they do not
share a common vulnerability
ī˛ Distribution is particularly important if the risk of denial of
service attacks is high
Chapter 13 Security Engineering 5712/11/2014
59. Design guidelines for security engineering
ī˛ Design guidelines encapsulate good practice in secure
systems design
ī˛ Design guidelines serve two purposes:
ī§ They raise awareness of security issues in a software
engineering team. Security is considered when design decisions
are made.
ī§ They can be used as the basis of a review checklist that is
applied during the system validation process.
ī˛ Design guidelines here are applicable during software
specification and design
Chapter 13 Security Engineering 5912/11/2014
60. Design guidelines for secure systems
engineering
Security guidelines
Base security decisions on an explicit security policy
Avoid a single point of failure
Fail securely
Balance security and usability
Log user actions
Use redundancy and diversity to reduce risk
Specify the format of all system inputs
Compartmentalize your assets
Design for deployment
Design for recoverability
Chapter 13 Security Engineering 6012/11/2014
61. Design guidelines 1-3
ī˛ Base decisions on an explicit security policy
ī§ Define a security policy for the organization that sets out the
fundamental security requirements that should apply to all
organizational systems.
ī˛ Avoid a single point of failure
ī§ Ensure that a security failure can only result when there is more
than one failure in security procedures. For example, have
password and question-based authentication.
ī˛ Fail securely
ī§ When systems fail, for whatever reason, ensure that sensitive
information cannot be accessed by unauthorized users even
although normal security procedures are unavailable.
Chapter 13 Security Engineering 6112/11/2014
62. Design guidelines 4-6
ī˛ Balance security and usability
ī§ Try to avoid security procedures that make the system difficult to
use. Sometimes you have to accept weaker security to make the
system more usable.
ī˛ Log user actions
ī§ Maintain a log of user actions that can be analyzed to discover
who did what. If users know about such a log, they are less likely
to behave in an irresponsible way.
ī˛ Use redundancy and diversity to reduce risk
ī§ Keep multiple copies of data and use diverse infrastructure so
that an infrastructure vulnerability cannot be the single point of
failure.
Chapter 13 Security Engineering 6212/11/2014
63. Design guidelines 7-10
ī˛ Specify the format of all system inputs
ī§ If input formats are known then you can check that all inputs are
within range so that unexpected inputs donât cause problems.
ī˛ Compartmentalize your assets
ī§ Organize the system so that assets are in separate areas and
users only have access to the information that they need rather
than all system information.
ī˛ Design for deployment
ī§ Design the system to avoid deployment problems
ī˛ Design for recoverability
ī§ Design the system to simplify recoverability after a successful
attack.
Chapter 13 Security Engineering 6312/11/2014
65. Aspects of secure systems programming
ī˛ Vulnerabilities are often language-specific.
ī§ Array bound checking is automatic in languages like Java so this
is not a vulnerability that can be exploited in Java programs.
ī§ However, millions of programs are written in C and C++ as these
allow for the development of more efficient software so simply
avoiding the use of these languages is not a realistic option.
ī˛ Security vulnerabilities are closely related to program
reliability.
ī§ Programs without array bound checking can crash so actions
taken to improve program reliability can also improve system
security.
12/11/2014 Chapter 13 Security Engineering 65
66. Dependable programming guidelines
12/11/2014 Chapter 13 Security Engineering 66
Dependable programming guidelines
1. Limit the visibility of information in a program
2. Check all inputs for validity
3. Provide a handler for all exceptions
4. Minimize the use of error-prone constructs
5. Provide restart capabilities
6. Check array bounds
7. Include timeouts when calling external components
8. Name all constants that represent real-world values
68. Security testing
ī˛ Testing the extent to which the system can protect itself
from external attacks.
ī˛ Problems with security testing
ī§ Security requirements are âshall notâ requirements i.e. they
specify what should not happen. It is not usually possible to
define security requirements as simple constraints that can be
checked by the system.
ī§ The people attacking a system are intelligent and look for
vulnerabilities. They can experiment to discover weaknesses
and loopholes in the system.
68Chapter 13 Security Engineering12/11/2014
69. Security validation
ī˛ Experience-based testing
ī§ The system is reviewed and analysed against the types of attack
that are known to the validation team.
ī˛ Penetration testing
ī§ A team is established whose goal is to breach the security of the
system by simulating attacks on the system.
ī˛ Tool-based analysis
ī§ Various security tools such as password checkers are used to
analyse the system in operation.
ī˛ Formal verification
ī§ The system is verified against a formal security specification.
69Chapter 13 Security Engineering12/11/2014
70. Examples of entries in a security checklist
Security checklist
1. Do all files that are created in the application have appropriate access permissions?
The wrong access permissions may lead to these files being accessed by unauthorized
users.
2. Does the system automatically terminate user sessions after a period of inactivity?
Sessions that are left active may allow unauthorized access through an unattended
computer.
3. If the system is written in a programming language without array bound checking, are
there situations where buffer overflow may be exploited? Buffer overflow may allow
attackers to send code strings to the system and then execute them.
4. If passwords are set, does the system check that passwords are âstrongâ? Strong
passwords consist of mixed letters, numbers, and punctuation, and are not normal
dictionary entries. They are more difficult to break than simple passwords.
5. Are inputs from the systemâs environment always checked against an input
specification? Incorrect processing of badly formed inputs is a common cause of
security vulnerabilities.
70Chapter 13 Security Engineering12/11/2014
71. Key points
ī˛ Security engineering is concerned with how to develop
systems that can resist malicious attacks
ī˛ Security threats can be threats to confidentiality, integrity
or availability of a system or its data
ī˛ Security risk management is concerned with assessing
possible losses from attacks and deriving security
requirements to minimise losses
ī˛ To specify security requirements, you should identify the
assets that are to be protected and define how security
techniques and technology should be used to protect
these assets.
Chapter 13 Security Engineering 7112/11/2014
72. Key points
ī˛ Key issues when designing a secure systems
architecture include organizing the system structure to
protect key assets and distributing the system assets to
minimize the losses from a successful attack.
ī˛ Security design guidelines sensitize system designers to
security issues that they may not have considered. They
provide a basis for creating security review checklists.
ī˛ Security validation is difficult because security
requirements state what should not happen in a system,
rather than what should. Furthermore, system attackers
are intelligent and may have more time to probe for
weaknesses than is available for security testing.
Chapter 13 Security Engineering 7212/11/2014