Secured Software Engineering

2023-04-21

Word count: 7.2k | Reading time≈ 42 min

The below case studies are given here in advance, they will be part of the final exam.

Case Study 1: You are part of a team that has been tasked with developing a web-based application for a healthcare organisation. The application will allow doctors to view patient information, including medical history, test results and treatment plans. Patients will also be able to access the application to view their own medical information and communicate with their doctors. The application will be used by a large number of healthcare providers and patients, and therefore security is a top priority. (Provided ahead of the exam)

Case Study 2: ABC airlines operates a large number of flights globally. In 2021, the airline suffered a significant data breach that affected the personal information of thousands of customers. In response to this breach, ABC airlines invested in a new approach to secure software engineering, including implementing secure coding practices, testing and validating software, and conducting regular security audits. The company has a complex network infrastructure that includes several web servers, database servers, and application servers. (Provided ahead of the exam)

案例研究1：你是一个团队的成员，他们的任务是为一个医疗机构开发一个基于网络的应用程序。该应用程序将允许医生查看病人信息，包括病史、测试结果和治疗计划。病人也可以访问该应用程序，查看他们自己的医疗信息，并与他们的医生沟通。该应用程序将被大量的医疗服务提供者和病人使用，因此安全性是重中之重。(该案例研究是期末考试的一部分，在考试前提供给大家)

案例研究2：ABC航空公司在全球范围内运营着大量的航班。2021年，该航空公司遭受了一次重大的数据泄露事件，影响了成千上万的客户的个人信息。为了应对这一漏洞，ABC航空公司投资了一种新的安全软件工程方法，包括实施安全编码实践，测试和验证软件，并定期进行安全审计。该公司有一个复杂的网络基础设施，包括几个网络服务器、数据库服务器和应用服务器。(在考试前提供)

1. Case Study: You are part of a team that has been tasked with developing a web-based application for a healthcare organization. The application will allow doctors to view patient information, including medical history, test results and treatment plans. Patients will also be able to access the application to view their own medical information and communicate with their doctors. The application will be used by a large number of healthcare providers and patients, so security is a top priority. (This case study is part of the final exam, provided ahead of the exam here)

(a) Identify and list down five use cases and five misuse cases of the system. [5]

Use Cases:

Registration: A new patient can securely register on the platform, providing their personal and contact information, and setting up a strong, unique password.
Medical Record Access: A doctor can access a patient’s medical history, including previous diagnoses, treatment plans, medications, and test results, to make informed decisions regarding the patient’s care.
Appointment Scheduling: Patients can use the application to schedule appointments with their healthcare providers, selecting available dates and times and receiving confirmation notifications.
Secure Messaging: Doctors and patients can communicate via a secure messaging platform within the application, discussing treatment plans, symptoms, and other healthcare-related topics.
Prescription Management: Healthcare providers can securely prescribe medications through the application, enabling patients to access their prescriptions and facilitating communication with pharmacies.

Misuse Cases:

Unauthorized Access: An attacker gains unauthorized access to a patient’s account, potentially viewing, altering, or deleting sensitive medical information, or even impersonating the patient.
Man-in-the-Middle Attack: An attacker intercepts the communication between the patient and the healthcare provider, potentially modifying the messages sent or received or eavesdropping on sensitive information.
Phishing Attacks: An attacker sends phishing emails or messages to patients, posing as a healthcare provider or the application itself, in an attempt to steal login credentials or other sensitive information.
Distributed Denial-of-Service (DDoS) Attack: An attacker overwhelms the application with a large volume of traffic, causing it to become unresponsive or slow, preventing healthcare providers and patients from accessing necessary information and services.
Security Misconfiguration: The application’s security settings are not properly configured, leaving it vulnerable to attacks and exposing sensitive patient data.

(b) List down five actors and five attackers of the system. [5]

Actors:

Patients, Doctors, Admin, Nurses, Patient Family.

Attackers:

General attackers, Payment gateway attackers, Nurses, Doctors, Patient Family.

(c) List down five high-level threats to the system. [5]

Insecure authentication
DDoS Attacks
Leakage of patients medical information. Implement a chain of custody to monitor on this system.
Attacker modify the information of patients and drug perscription for patients.
Large size file uploads/buffer overflow:

(d) Against each threat what would be your countermeasure? [5]

Introduce multi-factor authentication.
Add defence against DoS/DDoS attacks.
Implement a chain of custody to monitor on this system.
implement logging on website against all actions and audit to be performed by doctors.
implement max size limit for file submission and implement defence against buffer overflow.

2. (a) If requirements are introduced at a later stage in the project, what would be its impact on security?

Support your answer with an example. [3]

it often leads to incomplete or insufficient security measures, making the system vulnerable to threats and attacks.

Increased complexity: Adding new requirements can make the system more complex, which in turn makes it harder to analyze and secure. Complex systems are more prone to vulnerabilities, as they have more potential points of failure and attack.

Example: Imagine a web application that initially only required user authentication via username and password. If the project scope is changed to include multi-factor authentication, this introduces additional components such as SMS or email verification. The complexity of the system increases, making it more difficult to ensure that all security aspects are correctly implemented and that no vulnerabilities are introduced.

Insufficient time for security analysis and testing: Introducing new requirements late in the project often means that there is less time available for security analysis and testing, increasing the likelihood of vulnerabilities remaining undetected.

Example: If a new payment feature is added to an e-commerce website just before the project’s deadline, there may not be enough time to perform a thorough security analysis and test all potential attack vectors, such as SQL injection or cross-site scripting vulnerabilities.

Cost and resource constraints: Late requirement changes can lead to increased costs and put additional strain on resources. This can result in cutting corners on security measures or failing to allocate enough time for thorough security testing.

Incomplete integration of security measures: New requirements might not be fully compatible with existing security measures, requiring rework or additional implementation to ensure that the overall security posture remains strong.

Example: An organization decides to migrate its on-premises infrastructure to the cloud during the project’s later stages. This change requires a reassessment of the security measures in place, as cloud environments have different security considerations compared to on-premises infrastructure. If not addressed properly, this can lead to vulnerabilities in the cloud environment.

(b) An organisation is performing risk analysis during the development stage for their asset having an

estimated value of £100,000. The exposure factor of the asset is estimated to be 0.25 and annual

rate of occurrence is expected to be 0.5. Mitigating the risk will cost the organization £5,000, is it

feasible to fix the vulnerability in the code or not? [5]

If do not fix the vulnerablity, the annual lost will be £12500

So, it is very worthy to spend £5000 to fix this vulnerability.

(c) A company wants to do the audit of their software for GDPR compliance. Which three Secure

Software Engineering methods you would recommend for this purpose? Give a brief explanation

for each method. [6]

Biometric Recognition Multi-factor Authentication

(d) In the code given on the next page, identify which variables are considered tainted and identify

any two potential security vulnerabilities in the code and suggest how to fix them (write in your

own words, no coding is required). [6]

function authenticateUser(username, password) {

 var userCredentials = {

 username: username, 

 password: password 

 };

 var input = document.getElementById("input").value; 

 if (isValidEmail(input)) {

 userCredentials.email = input; 

 }

 $.post("/login", userCredentials, function(response) {

 if (response.success) {

 alert("You are logged in!");

 } else {

alert("Authentication failed.");

 }

 });

}

function isValidEmail(email) {

 var emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

 return emailRegex.test(email); 

}

tainted varaibles:

userCredentials中的username和userpassword可能受污染，因为他是直接从传入的参数中获得的，

input变量同样是直接从页面中获取的，可能收到污染

solution

对于用户名和密码，进行表单提交，并且进行表单认证，并且对于用户名和密码进行安全编码，同时对用户的输入进行输入检查，如dompurify的库可以帮助做到这一点

对于发送的 POST 请求，应该使用 HTTPS 协议进行通信，并对用户输入的敏感信息进行加密或者哈希处理，避免被劫持或者窃取。可以使用加密算法、哈希算法或者 SSL/TLS 协议来保证通信安全。

代码中有两个潜在的安全漏洞:

跨站脚本漏洞:

代码接受用户输入(用户名和密码)，并直接将其发送到服务器，而没有进行适当的验证或处理。如果攻击者将恶意脚本注入到输入字段中，服务器可能会执行这些脚本，从而可能危及应用程序。

要修复此漏洞，您应该在将用户输入发送到服务器之前对其进行清理和验证。您可以使用像DOMPurify这样的库来净化输入，并创建一个验证函数来检查输入字段中的任何无效字符。

敏感数据的不安全传输:

该代码将用户的凭据(用户名和密码)以明文形式发送到服务器，而不进行任何加密。这可能会将敏感信息暴露给潜在的窃听者或攻击者，特别是在连接没有使用HTTPS保护的情况下。

为了解决这个问题，你应该确保你的网站使用HTTPS，它加密客户端和服务器之间传输的数据。此外，考虑实现更安全的身份验证机制(如OAuth2)或使用密码散列技术(如bcrypt)来安全地存储和传输密码。

(e).

(a). You are being asked to consult with a start-up who are looking to put together a security policy for integrity. You are told that there are three security levels for the objects: o1 < o2 <o3 where o3 is the highest and o1 is the lowest security level. The following table present the associated security levels and categories for the objects (o). The subjects S1 lies on Level 1, S2 lies on Level 2 and S3 lies on Level 3. Fill out the following table to indicate all applicable permissions when the Simple Security Property is applied. Write -p’ for read and ‘-w’ for write and ‘-rw’ for both read and write operations. If a Subject is not authorized to perform any action, leave the cell blank. [8]

	O1	O2	O3
S1	-r
S2	-r	-r
S3	-r	-r	-r

Table 1: A security model indicating subject and object integrity levels

(b). How an organization can effectively apply confidentiality and integrity in their software products?

Provide a brief explanation of the consequences.

(c). ABC airlines operates a large number of flights globally. In 2021, the airline suffered a significant data breach that affected the personal information of thousands of customers. In response to this breach, ABC airlines invested in a new approach to secure software engineering, including implementing secure coding practices, testing and validating software, and conducting regular security audits. The company has a complex network infrastructure that includes several web servers, database servers, and application servers. Now, the airline company wants to implement confidentiality and integrity in their system, how it will be done? List any three suggestions.

(d). Why it is important to rank stakeholders in the system? Provide an example scenario and rank 3 different stakeholders in it.

Reason:

The ranking is important to satisfy the competing needs,Contradiction of needs e.g., privacy in one case can conflict with requirement to send name and email in other case.

Candidate stakeholders are: end users, project manager, CEO, CIO, team lead, network admin, db manager, marketing department, legal department and sales team.

Number of external stakeholders is limited

revision

Risk

Risk and Risk management

Risk is the potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization
Risk management— “Process of identifying, controlling and minimizing or eliminating security risks that may affect information systems, for an acceptable cost.”
Risk assessment—“assessment of threats to, impact on and vulnerabilities of information and information processing facilities and the likelihood of their occurrence.”

Who is the enemy? Why do they do it?
• Offenders

Crackers—mostly teenagers doing as intellectual challenge
Information system’s criminals—Espionage and/or
Fraud/abuse—for a nation/company to gain a competitive advantage over its rivals
Vandals—authorized users and strangers (cracker or a criminal)—motivated by anger directed at an individual/organization/life in general

Risk = Threats × Vulnerabilities

Risk	Threats	Vulnerabilities
business disruption	angry employees	software bugs
financial losses	dishonest employees	broken processes
loss of privacy	criminals	ineffective controls
damage to reputation	governments	hardware flaws
loss of confidence	terrorists	business change
legal penalties	the press	legacy systems
impaired growth	competitors	Inadequate BCP
loss of life	hackers	human error
	nature

Types of Damage

Interruption—destroyed/unavailable services/resources
Interception—unauthorized party snooping or getting access to a resource
Modification— unauthorized party modifying
a resource
Fabrication—unauthorized party inserts a fake asset/resource

The purpose of risk management

Ensure overall business and business assets are safe
Protect against competitive disadvantage
Compliance with laws and best business practices
Maintain a good public reputation

Accountability for Risk Management

It is the responsibility of each community of interest to manage risks; each community has a role to play:
Information Security - best understands the threats and attacks that introduce risk into the organization
Management and Users - play a part in the early detection and response process - they also insure sufficient resources are allocated
Information Technology - must assist in building secure systems and operating them safely

Steps of a risk management plan

Step 1: Identify Risk
Step 2: Assess Risk
Step 3: Control Risk
Steps are similar regardless of context (InfoSec, Physical Security, Financial, etc.)
This presentation will focus on controlling risk within an InfoSec context

Risk Identification

The steps to risk identification are:
Identify your organization’s information assets
Classify and categorize said assets into useful groups
Rank assets necessity to the organization

To the right is a simplified example of how a company may identify risks

Risk Assessment

The steps to risk assessment are:
Identify threats and threat agents
Prioritize threats and threat agents
Assess vulnerabilities in current InfoSec plan
Determine risk of each threat

R=P*V-M+ U

R= Risk

P= Probability of threat attack

V = Value of Information Asset

M = Mitigation by current controls

U = Uncertainty of vulnerability

Risk control

The steps to risk control are:
Cost-Benefit Analysis (CBA)
- Single Loss Expectancy (SLE)
- Annualized Rate of Occurrence (ARO)
- Annual Loss Expectancy (ALE)
- Annual Cost of the Safeguard (ASG)
Feasibility Analysis
- Organizational Feasibility
- Operational Feasibility
- Technical Feasibility
- Political Feasibility
Risk Control Strategy Implementation

Cost-Benefit analysis

Determine what risk control strategies are cost effective
Below are some common formulas used to calculate cost-benefit analysis
SLE = AV * EF
- AV = Asset Value, EF =
  Exposure factor (% of asset affected)
ALE = SLE * ARO
CBA = ALE (pre-control) -

ALE (post-control) - ACE(Annually Countermeasure Expectancy)

SLE - single loss expectancy, ALE - Annual loss expectancy, CBA – Cost benefit analysis

Feasibility analysis

Organizational: Does the plan correspond to the organization’s objectives? What is in it for the organization? Does it limit the organization’s capabilities in any way?

Operational: Will shareholders (users, managers, etc.) be able/willing to accept the plan? Is the system compatible with the new changes? Have the possible changes been communicated to the employees?

Technical: Is the necessary technology owned or obtainable? Are our employees trained and if not can we afford to train them? Should we hire new employees?

Political: Can InfoSec acquire the necessary budget and approval to implement the plan? Is the budget required justifiable? Does InfoSec have to compete with other departments to acquire the desired budget?

Risk control Strategies

Defense
Transferal
Mitigation
Acceptance (Abandonment)
Termination

Risk control Strategy: defense

• Defense: Prevent the exploitation of the system via application of policy, training/education, and technology. Preferably layered security (defense in depth)

% Counter threats

% Remove vulnerabilities from assess

% Limit access to assets

§ Add protective safeguards

Figure 1-Application Security Layered Approach

Risk control Strategy: transferal

Transferal: Shift risks to other areas or outside entities to handle
Can include:

% Purchasing insurance

• Outsourcing to other organizations

* Implementing service contracts with providers
§ Revising deployment models

Risk control Strategy: Mitigation

Risk control Strategy: Acceptance

Appropriate when:

% The cost to protect an asset or assets exceeds the cost to replace it/them

When the probability of risk is very low and the asset is of low priority
Otherwise acceptance = negligence

Risk control Strategy: Termination

Termination: Removing or discontinuing the information asset from the organization
Examples include:

Equipment disposal

Discontinuing a provided service

Firing an employee

Pros and cons of each strategy

Standard approaches to risk management

U.S CERT’s Operationally Critical Threat Assessment
Vulnerability Evaluation (OCTAVE) Methods (Original, OCTAVE-S, OCTAVE-Allegro)
ISO 27005 Standard for InfoSec Risk Management
NIST Risk Management Model
Microsoft Risk Management Approach
Jack A. Jones’ Factor Analysis of Information Risk
(FAIR)
Delphi Technique

Risk Determination

For the purpose of relative risk assessment:

RISK =

likelihood of vulnerability occurrence times value (or impact)

MINUS

percentage risk already controlled

PLUS

an element of uncertainty

Access Controls

One particular application of controls is in the area of access controls
Access controls are those controls that specifically address admission of a user into a trusted area of the organization
There are a number of approaches to controlling access
Access controls can be
discretionary
mandatory
nondiscretionary

Types of Access Controls

Discretionary Access Controls (DAC) are implemented at the discretion or option of the data user
Mandatory Access Controls (MACs) are structured and coordinated with a data classification scheme, and are required
Nondiscretionary Controls are those determined by a central authority in the organization and can be based on that individual’s role

Lattice-based Control

Another type of nondiscretionary access is lattice-based control, where a lattice structure (or matrix) is created containing subjects and objects, and the boundaries associated with each pair is contained
This specifies the level of access each subiect has to each object
In a lattice-based control the column of attributes associated with a particular object are referred to as an access control list or ACL
The row of attributes associated with a particular subiect (such as a user) is referred to as a capabilities table
This is part of Principles of Information SecurityPrinciples of Information Security

Documenting Results of Risk Assessment

The goal of this process has been to identify the information assets of the organization that have specific vulnerabilities and create a list of them, ranked for focus on those most needing protection first
In preparing this list we have collected and preserved factual information about the assets, the threats they fac and the vulnerabilities they experience
We should also have collected some information about the controls that are already in place

Asset Identification and Valuation

This iterative process begins with the identification of assets, including all of the elements of an organization’s system
Then, we classify and categorize the assets adding details as we dig deeper into the analysis

Components of an Information System

Hardware, Software, and Network Asset Identification

• Automated tools can sometimes uncover the system elements that make up the hardware, software, and network components

Once created, the inventory listing must be kept current, often through a tool that periodically refreshes the data

What attributes of each of these information assets should be tracked?
When deciding which information assets to track, consider including these asset attributes:

Name

IP address

MAC address

Element type

Serial number

Manufacturer name

People, Procedures, and Data Asset Identification

Unlike the tangible hardware and software elements already described, the human resources, documentation, and data information assets are not as readily discovered and documented
These assets should be identified, described, and evaluated by people using knowledge, experience, and judgment
As these elements are identified, they should also be recorded into some reliable data handling process

Asset Information for People

For People:
- Position name/number/ID - try to avoid names and stick to identifying positions, roles, or functions
- Supervisor
- Security clearance level
- Special skills

Asset Information for Procedures

For Procedures:
- Description
- Intended purpose
- What elements is it tied to
- Where is it stored for reference
- Where is it stored for update purposes

Asset Information for Data

For Data:
- Classification
- Owner/creator/manager
- Size of data structure
- Data structure used - sequential, relational
- Online or offline
- Where located
- Backup procedures employed

Information Asset Classification

Many organizations already have a classification scheme
Examples of these kinds of classifications are:
- confidential data
- internal data
- public data
Informal organizations may have to organize themselves to create a useable data classification model
The other side of the data classification scheme is the personnel security clearance structure

Information Asset Valuation

Each asset is categorized
Questions to assist in developing the criteria to be used for asset valuation:
- Which information asset is the most critical to the success of the organization?
- Which information asset generates the most revenue?
- Which information asset generates the most profitability?
- Which information asset would be the most expensive to replace?
- Which information asset would be the most expensive to protect?
- Which information asset would be the most embarrassing or cause the greatest liability if revealed?

Examples of Information Security Vulnerabilities

Information security vulnerabilities are weaknesses that expose an organization to risk.
Through employees: Social interaction, Customer interaction,
Discussing work in public locations,
Through former employees—Former employees working for competitors, Former employees retaining company data,
Former employees discussing company matters
Though Technology—Social networking, File sharing, Rapid technological changes, Legacy systems, Storing data on mobile devices such as mobile phones, Internet browsers
Through hardware—. Susceptibility to dust, heat and humidity,
Hardware design flaws, Out of date hardware,
Misconfiguration of hardware

Examples of Information Security Vulnerabilities (Cont.)

Through software—Insufficient testing, Lack of audit trail, Software bugs and design faults, Unchecked user input, Software that fails to consider human factors, Software complexity (bloatware), Software as a service (relinquishing control of data), Software vendors that go out of business or change ownership
Through Network—Unprotected network communications, Open physical connections, IPs and ports, Insecure network architecture, Unused user ids, Excessive privileges, Unnecessary jobs and scripts executing, Wifi networks
Through IT Management—Insufficient IT capacity, Missed security patches, Insufficient incident and problem management, Configuration errors and missed security notices, System operation errors
Partners and suppliers—Disruption of telecom services, Disruption of utility services such as electric, gas, water, Hardware failure, Software failure, Lost mail and courier packages, Supply disruptions, Sharing confidential data with partners and suppliers

Programme Criticality

The programme criticality framework is a common
United Nations system framework for decision-making that puts in place a systematic structured approach that uses programme criticality as a way to ensure that programme activities can be balanced against security risks.
The concept of criticality means the critical impact of an activity on the population, not necessarily on the organisation.
Programme criticality assessment is mandatory in areas with residual risk levels of ‘high’ and very high,’ as determined in the Security Risk Assessments (SRAs).
Primary accountability for programme criticality is with United Nations senior management at the country level.

A programme criticality assessment has steps as follows:

1. Establish geographical scope and timeframe
2. List strategic results (SRs)
3. List UN activities/outputs (involving UN personnel)
4. Assess contribution to strategic results
5. Assess likelihood of implementation
6. Evaluate activities/outputs with PCI criteria
7. View PC level results, form consensus within the UN system and approve final results
8. Agree on a process to address and manage the results of the PC
assessment
9. Follow-up and review.
There are two possible criteria for an activity to be considered a PCI activity:
- Either the activity is assessed as lifesaving (humanitarian or non-humanitarian) at scale (defined as any activity to support processes or services, including needs assessments), that would have an immediate and significant impact on mortality; or
- The activity is a directed activity that receives the endorsement of the Office of the Secretary-General for this particular situation.
Risk level has no impact on programme criticality.
There must be no consideration of risk level when determining PC.
Programme criticality has no impact on risk level.
There must be no consideration of PC when determining risk level.

Other Processes with Security Implications

Intelligence and Information Cycle.
Strategic-level Integrated Mission Planning Process.
Mission-level Integrated Planning, Coordination and implementation.
Mission Component Planning and Implementation
Processes.
UN Budget Processes.
Staff Selection and Managed Mobility System.
Any other process that impacts the substance of UN security.

Security Patterns

Values of security pattern:

Security patterns can apply security principles, guide the design and implementation, guide the use of security mechanisms,help understanding and use of complex **standards (**XACML, WiMax) and Convenient for teaching security principles and mechanisms.

An Abstract Security Pattern (ASP), describes a conceptual security mechanism that realizes one or more security policies able to control (stop or mitigate) a threat or comply with a security-related regulation or institutional policy (no implementation aspects).

Conceptual security

Security is a quality aspect that constrains the semantic behavior of applications (by imposing access restrictions), so the requirements stage is the right development stage to start addressing security
However, we only want to indicate at this stage which specific security controls are needed, not their convenient or optimal implementation.
For example, in bank applications we only want to specify the semantic aspects of accounts, customers, and transactions with their corresponding restrictions.

An ASP example: Authenticator:

This is the Intent section of an Authenticator pattern: “When a user or system (subject) identifies itself to the system, how do we verify that the subject intending to access the system is who it says it is? Present some information that is recognized by the system as identifying this subject.
After being recognized, the requestor is given some proof that it has been authenticated.”
Authentication restricts access to a system to only registered users; it handles the threat where an intruder enters a system and may try to perform unauthorized access to information
It is clear that there are many ways to perform this authentication, that go from manual ways, as done in voting places, to purely automatic ways, as when accessing a web site, but all of them must include the requirements of the abstract Authenticator

Authentication as an abstract function requires a basic sequence of activities. Concrete realizations of this sequence implement these steps in different ways but all must perform these two steps: • The subject requests to enter a system indicating its identity and presenting some proof of identity. • If the system recognizes the subject using its identity information, it grants her entrance to the system and provides her with a proof of authentication for further use. If not, the request is denied. • We can define a hierarchy of authentication patterns starting from the abstract Authenticator

Force os abstract authenticator

Closed system. If the authentication information presented by the user is not recognized, there is no access. In an open system all subjects would have access except some who are blacklisted for some reason.
Registration. Users must register their identity information so that the system can recognize them later.
Flexibility. There may be a variety of individuals (users) who require access to the system and a variety of system units with different access restrictions. We need to be able to handle all this variety appropriately or we risk security exposures.
Dependability. We need to authenticate users in a reliable and secure way.

This means a robust protocol and a high degree of availability. Otherwise, users may fool the authentication process or enter when the system authentication is down.
Protection of authentication information. Users should not be able to read or modify the authentication information. Otherwise, they can give themselves access to the system.
Simplicity. The authentication process must be relatively simple or the users or administrators may be confused. User errors are annoying to them but administrator errors may lead to security exposures.
Reach. Successful authentication only gives access to the system, not to any specific resource in the system. Access to these resources must be controlled using other mechanisms, typically authorization.
Tamper freedom. It should be very difficult to falsify the proof of identity presented by the user.
Cost. There should be tradeoffs between security and cost, more security can be obtained at a higher cost.
Performance. Authentication should not take a long time or users will be annoyed.
Frequency. We should not make users authenticate frequently. Frequent authentications waste time and annoy the users.
All these properties must be present in the lower-level ways of performing authentication, e.g. in a Password Authenticator (see next slide). A Password Authenticator needs tomake concrete its Authentication Information (list of passwords) and its proof of authentication (a session)

Reference Monitor

Authorization rules define who has access to what and how. They must be enforced when a process request a resource
Each request for resources must be intercepted and evaluated for authorized access; this is the concept of Reference Monitor
An abstract concept, implemented as memory access manager, file permission checks, CORBA adapters, etc.

Role-Based Access Control

Users are assigned roles according to their functions and given the needed rights (access types for specific objects)
When users are assigned by administrators, this is a mandatory model
Can implement least privilege and separation of duty policies

XML firewall

• Controls input/output of XML applications

• Well-formed documents (schema as reference)

• Harmful data (wrong type or length)

• Encryption/decryption

• Sign and verify signatures in documents

Building secure systems

Secure systems need to be built in a systematic way where security is an integral part of the lifecycle, and the same applies to safety.
The platform should match the type of application, and all compliance, safety and security constraints should be defined at the application level, where their semantics are understood and propagated to the lower levels.
The lower levels must provide the assurance that the constraints are being followed, i.e., they implement these constraints and enforce that there are no ways to bypass them.
Following these ideas, the Authors of the book in reference developed a secure systems development methodology, which considers all lifecycle stages and all architectural levels. It is expanded with architectural aspects, and recently with process aspects.

Security methodology:

systematic way of introducing security into a software system during the development life-cycle

Consists of two aspects/facets:security process(SP) and conceptualsecurity framework (CF)

ASE: a comprehensive security methodology for distributed systems

Many methodologies exist with different paradigms
Very important class is methodologies that use security patterns
ASE: a security methodology using patterns and related constructs designed specifically for general distributed systems

Basic security principles for system design

Security constraints must be defined at the highest layer, where their semantics are clear, and propagated to the lower levels, which enforce them.
All the layers of the architecture must be secure.
We can define patterns at all levels. This allows a designer to make sure that all levels are secured, and also makes easier propagating down the high-level constraints.
We must apply security in all development stages
A two-dimensional approach: time and space

Reference Architecture (RA)

• A Reference Architecture (RA) is a generic software architecture, based on one or more domains, with no implementation aspects
• An RA is reusable, extendable, and configurable.
• It specifies the components of the system, their individual functionalities and their mutual interaction.
• An RA can be considered as a compound pattern and its components described as patterns.
• In addition to domain models, an RA may include a set of use cases (UC), and a set of Roles (R) corresponding to its stakeholders actors).

We can measure security by counting the threats that have been neutralized by using patterns

Incident Response Plan

• Before system is released, an incident response plan should be created (compromise or failure)

• Contact personnel, availability and procedures for multiple levels of failure

• A minor glitch does not require CEO to be informed but should be documented

• Network admin or security admin to determine an appropriate response when incident occurs

Key elements of incident response plan:

Monitoring duties for the software in live operation
A definition for incidents
A contact for incidents
An emergency contact for priority incidents
A clear chain of escalation
Procedures for shutting down the software or components of the software
Procedures for specified exploits or attacks
Security documentation or the references for external ode or hardware used

*It depends on the organization that the person responsible is from development team or outside

evolving attacks / periodic review and archiving

Web Application Threats

Never trust the client at the server side
Never trust the browser on the client side
Never execute client input as code
Never allow client input to pass into the system without validation internally
Scrub client for any known exploits and suspect characters

XSS

CSRF

File Upload

Buffer Overflow

SQL Injection

Threat Modelling

• In a nutshell, threat modelling is the use of abstractions to help you consider risks.
• Involves developing a shared understanding of a product or service architecture and the problems that could happen.
•When you model threats, you typically use one of two types of model.

The model for what you are building.
The model for the threats of what you are building.

The Four-Step Framework

Model System, Model the system you’re building, deploying or changing.
Find Threats, Find threats using the model.
Addrasc Inrears, Address the threats.
Validate,Validate, the result for completeness and effectiveness

(1) What are you Building?

Diagrams are a good way to communicate what you are building.
There are lots of ways to diagram software and you can start with a whiteboard diagram of how data flows through the system.

(2) What can go wrong?

Given a simple diagram, we can start thinking about what can go wrong. Example:
How do you know that the web browser is being used by the person you expect?
What happens if someone modifies data in the database?
Is it okay for information to move from one box to the next without encryption?
You can identify threats like these using the STRIDE approach.
Use STRIDE to walk through each part of the diagram:
Spoofing.
Tampering.
Repudiation.
Information Disclosure.
Denial of Service.
Elevation of Privilege.

(3) What Are We Going To Do About It

• There are four types of action you can take against a threat:

Mitigate it.

Eliminate it. Vpn（Geo-restrictions: A VPN can be used to bypass geo-restrictions and access content that may be blocked in certain regions, reducing the risk of inadvertently visiting malicious websites or downloading malicious content.）
Transfer it.
Accept it

(4) Did We Do A Good Job

Look at the diagram, does it represent the system well?
Look at the list of threats, did you find at least 5 threats per node in the diagram?
Did you file a bug per threat?

When you find threats that violate your requirements and cannot be mitigated, it generally makes sense to adjust your requirements.
Sometimes it’s possible to either mitigate the threat operationally, or defer a decision to the person using the system.
There are many other threat modelling techniques, we have only touched most popular approaches.
Some other threat modelling approaches include:
PASTA (Process for Attack Simulation and Threat Analysis)
CSVSS Common Vulnerability Scoring System)
HMM (Hybrid Threat Modelling Method)

Attack Trees

Top level node (or root) represents the ultimate goal of an attacker.
The nodes (or leaves) represent sub goals that need to be achieved (together or independently) to arrive at the top level goal.

• An alternative to STRIDE(Spoofing, tampering, repudiation, Information disclosure,Denial of service,Denial of service).

• You can use attack trees as a way to find threats, or as a way to organize threats.

• Attack trees work well as a building block for threat enumeration in the fourstep framework.

We can use attack trees to find the threats

Attack-Defence Scenarios

• Attack trees are used to model attack-defence scenarios.

• The attack-defence scenario is a game between two players:

• The proponent (denoted as p)

• The opponent (denoted as o)

The root of an attack tree represents the main goal of the proponent.
- When the root is an attack node, the proponent is an attacker and the opponent is a defender.
- Conversely, when the root is a defence node, the proponent is a defender and the opponent is an attacker.
Notations:
Attack nodes are represented with circles.
Defence nodes are represented with rectangles.
Refinements:
- Refinements can be conjunctive (AND aggregation) or disjunctive (OR choice)
- Refinement relations are indicated by solid edges between nodes.
- Countermeasures are indicated by dotted edges.
- A conjunctive refinement of a node is represented by an arc over all edges connecting the node and its children of equal type.

The basic steps to create an attack tree are as follows:

\1. Decide on a representation.

Two types of trees:

AND trees (aggregation): The state of a node depends on all of the nodes below it being true. 有夹脚

Or trees (choice): A node is true if any of its subnodes are true. 没夹脚

\2. Create a root node.

If the root node is a countermeasure mitigation action…

Then the subnodes are used to identify what can go wrong.

Decompose the mitigation action and identify how the results can be threatened.

If the root node is a goal of the attacker:

Then we consider ways to achieve that goal.

Each alternative way to achieve the goal should be drawn as a subnode.

\3. Create subnodes.

• You typically create subnodes by brainstorming in some structured manner.

• The relation between subnodes and parent node can be AND or OR.

• Some possible structures for first-level subnodes include:

Attacking a system:

Physical access.
Subvert software.
Subvert a person.

Attacking a system via:

People.
Process.
Technology.

Attacking a product during:

Design.
Production.
Distribution.
Usage.

\4. Consider completeness.

• An attack tree can be checked for quality by iterating over the node, looking for additional ways to reach the goal. It may be helpful to use STRIDE or attack libraries.

\5. Prune the tree.

• In this step, go through each node in the tree and consider whether the action in each subnode is prevented or duplicative.

\6. Check the presentation.

• Trees can be represented in two ways:

• As a free form (human viewable) model without any technical structure.

• As a structured representation with variable types and/or metadata to facilitate programmatic analysis.

Human Viewable Representations

• Attack trees can be drawn graphically or shown in outline form.

• Care should be taken to ensure that the graphics are actually information rich and useful.

• Outline representations are easier to create than graphical representations, but they tend to be less attention-grabbing.

• If you are using someone else’s tree, be sure to understand their intent. If you are creating once, be sure you are clear on your intent and communicate your intent clearly.

Risk Analysis

• Risk = (Probability of Incident) x (Incident Impact)

• When dealing with hostile risk, consider the following:

• Vulnerabilities in systems are NOT constants.

• Capabilities of the adversary are NOT constant.

• Motivators for adversary changes instantaneously.

• Adversaries can attack your system anytime.

Probability of Incident = Vulnerability x Threat x Motivation

Security Functional Requirements

FAU: Security auditing.
FCP: Communications.
FCS: Cryptographic support.
FDP: User data protection.
FIA: Identification and authentication.
FMT: Security management.
FPR: Privacy.
FPT: Protection of security function.
FRU: Resource utilization.
FTA: Access.
FTP: Trusted path.

Security Mechanismss

There are several ways in which the security policy can be enforced.
Assurance requirements detail the ways in which security is demonstrated.
There are also different ways of evaluating these requirements.
Here are the FIPS standards.

Donate

Copyright： Copyright is owned by the author. For commercial reprints, please contact the author for authorization. For non-commercial reprints, please indicate the source.