Macro Assignment 1

Name of student(s)

Ayush Negi [20104021]

Aviral Agrohi [20104003]

Shivam Negi[20104036]

Ojus Chugh [20104046]

TOPIC: INNOVATIVE MOBILE APPLICATION “CAB BUDDY : YOUR OWN CAB”

Submitted to:

SANDEEP KUMAR SINGH

Secure Design of Software Systems

Department of CSE/IT
Jaypee Institute of Information Technology University, Noida
(a)
A significant facet of student life is the daily commute between college and accommodation. For
those fortunate enough to have fellow students residing nearby, ride-sharing becomes not only a
cost-effective transportation solution but also a means of reducing environmental impact and
fostering social connections. The concept of carpooling has gained immense popularity in
recent times, primarily driven by the ever-increasing expenses of daily life. In response to this
need, we have developed an innovative mobile application called "Cab Buddy." Cab Buddy
serves as a platform for people to connect with others seeking travel companions, with a focus
on simplifying and enhancing the daily commute experience.

The Challenge at JIIT 128 and JIIT 62

At Jaypee Institute of Information Technology (JIIT), the daily commute between its Sector 128
and Sector 62 campuses presents a common and recurring challenge for students. This
challenge is particularly pronounced among students who reside in the hostels at JIIT 62 and
need to travel between these two campuses on a regular basis. While cabs and auto-rickshaws
offer unmatched convenience for this commute, a significant hurdle persists—the absence of an
efficient means to find travel companions.

The Problem Statement

The problem statement we aim to address revolves around the need to develop an Android
application that simplifies and streamlines ride-sharing among students at JIIT, particularly those
commuting between JIIT 128 and JIIT 62. The issues at hand encompass the following key
elements:

1. Cost Concerns: Traveling alone in a cab or auto-rickshaw can be financially burdensome for
students, especially when done daily. The problem statement involves providing students with a
means to reduce transportation costs significantly.

2. Connectivity Issues: The current lack of a central platform or mechanism for connecting
students with similar commuting routes and schedules is a significant challenge. The problem
statement seeks to bridge this gap by fostering connectivity and community among students.

3. Environmental Impact: Promoting sustainable transportation practices is vital. The

application aims to encourage ride-sharing, thereby reducing the number of vehicles on the
road, cutting down emissions, and contributing to a greener environment.

4. Social Connections: Beyond the cost savings and environmental benefits, ride-sharing
offers students the opportunity to socialize, make new friends, and expand their network within
the university community. The application should facilitate these social interactions.
5. Ease of Use: The problem statement includes the development of an intuitive and
user-friendly Android application that caters to students of varying technological backgrounds,
ensuring they can easily navigate and utilize the platform.

6. Safety and Security: Ensuring the safety of users is paramount. The application should
implement robust safety measures, including user verification, emergency contact options, and
ride tracking, to instill confidence in users.

In summary, our project's problem statement revolves around creating a comprehensive solution
in the form of the Cab Buddy Android application. This solution aims to address the cost
concerns and connectivity issues faced by students at JIIT 128 and JIIT 62 during their daily
commutes. By doing so, we intend to promote cost-effective, environmentally-friendly, and
community-driven transportation practices among the student population.

(b) When assessing the security of a system, it's crucial to identify potential assets,
vulnerabilities, and threats. In the context of your Cab Buddy application, here are some
possible assets, vulnerabilities, and threats:

Assets:

User Data: Information provided by users during registration, including names, contact details,
and commuting preferences.

User Accounts: User accounts and profiles within the application.

Location Data: Real-time or historical location data used for ride-sharing matching.

Payment Information: If payment processing is involved (e.g., for ride cost-sharing), financial
data such as credit card information or digital payment details.

Application Code and Data: The software code, algorithms, and data used to match users and
facilitate ride-sharing.

Server Infrastructure: The servers and databases hosting user data and application logic.

User Reviews and Ratings: User-generated content such as reviews and ratings for drivers or
co-passengers.

Communication Channels: In-app messaging and communication channels used for

coordination.
Vulnerabilities:

Inadequate User Authentication: Weak or poorly implemented user authentication processes

that could lead to unauthorized access.

Data Encryption Weakness: Insufficient data encryption during transmission and storage,
making data interception easier.

Insecure APIs: Vulnerabilities in the application programming interfaces (APIs) used for
communication with external services or platforms.

Code Vulnerabilities: Security flaws, such as SQL injection or Cross-Site Scripting (XSS),
within the application's code.

Insufficient Access Controls: Failing to implement proper access controls, allowing

unauthorized users to access sensitive data or functionality.

Server Vulnerabilities: Weaknesses in the server infrastructure, including outdated software or

misconfigured settings.

User Privacy: Mishandling or misuse of user data, leading to privacy breaches.

Payment Processing Security: Vulnerabilities in payment processing that could result in

financial fraud.

Communication Security: Lack of encryption and secure protocols for in-app communication.
Scalability Issues: System performance and scalability problems under heavy loads or attacks.

Threats:

Unauthorized Access: Attackers gaining unauthorized access to user accounts or sensitive

data.

Data Breaches: The exposure or theft of user data, which can lead to identity theft or privacy
violations.
Financial Fraud: Fraudulent activities related to payment information or financial transactions
.
Malware and Phishing: Users falling victim to malware, phishing, or social engineering attacks.

Denial of Service (DoS) Attacks: Overwhelming the application with traffic to disrupt its
availability.

API Attacks: Exploitation of vulnerabilities in APIs to compromise data or functionality.

Code Exploitation: Exploiting code vulnerabilities to execute malicious actions.

Insider Threats: Unauthorized actions or data breaches by employees or trusted individuals.

Privacy Violations: Unauthorized sharing or use of user data.

Reputation Damage: Negative user reviews, ratings, or social media backlash affecting the
application's reputation.
Identifying these assets, vulnerabilities, and threats is essential for developing a robust security
strategy and implementing measures to mitigate potential risks in your Cab Buddy system.

(c) Use cases represent the various interactions and functionalities within a system from the
perspective of its users. In the context of your Cab Buddy application, here are some possible
use case scenarios:

User Registration:

Actor: New User

Description: The user creates a new account by providing personal information, including
name, contact details, and commuting preferences.
User Login:

Actor: Registered User

Description: The user logs into the application using their credentials to access their account
and utilize its features.
Find a Ride:

Actor: User Seeking a Ride

Description: The user searches for available rides based on their current location, destination,
and preferred travel times.
Offer a Ride:

Actor: User Offering a Ride

Description: The user creates a ride-sharing offer, specifying details such as pickup location,
destination, departure time, and the number of available seats.
Match with Co-passengers:

Actor: User Offering a Ride / User Seeking a Ride

Description: The system matches users with similar commuting routes, schedules, and
preferences for ride-sharing.
Coordinate and Chat:

Actor: Matched Users

Description: Users who are matched for ride-sharing can communicate through an in-app chat
to coordinate pickup points, drop-off points, and any other logistics.
Payment Processing:

Actor: User Offering a Ride / User Seeking a Ride

Description: Users may set up payment methods and process payments for cost-sharing, if
applicable.
Review and Rating:

Actor: Users Completing a Ride

Description: After a ride is completed, users can provide reviews and ratings for their
co-passengers or drivers.
Manage Profile:

Actor: Registered User

Description: Users can update their profile information, including contact details, commuting
preferences, and payment methods.
Emergency Assistance:

Actor: Any User

Description: In case of emergencies or safety concerns during a ride, users can use an
emergency assistance feature to alert authorities or share their location with trusted contacts.

(d)

[Link]. Requirement Type Requirement Statement

1 User Authentication Users must authenticate

securely before accessing the
application.

2 Data Encryption All sensitive data, including

user information and
communication, must be
encrypted during
transmission and storage.

3 Authorization Users should have

appropriate access rights
based on their roles and
permissions.

4 Secure APIs APIs used for communication

with external services must
 be secured against
unauthorized access and
attacks.

5 Code Security The application's code must

be regularly reviewed and
tested for security
vulnerabilities, such as SQL
injection or Cross-Site
Scripting (XSS).

6 Access Controls Proper access controls

should be in place to prevent
unauthorized access to
sensitive data or functionality.

7 Server Security Server infrastructure must be

secured, including regular
updates, patch management,
and intrusion detection
systems.

8 Data Privacy User data privacy must be

protected, and data handling
practices should comply with
relevant regulations (e.g.,
GDPR).

9 Payment Security If processing payments, the

application must comply with
Payment Card Industry Data
Security Standard (PCI DSS)
requirements.

10 Secure Communication In-app communication

channels must use secure
protocols and encryption.

11 Secure Authentication Passwords must be securely

hashed and stored, and
multi-factor authentication
(MFA) should be encouraged.

12 Data Backups Regular data backups should

be performed to prevent data
loss in case of system
failures or security incidents.

13 Incident Response An incident response plan

should be in place to handle
security breaches and
 incidents promptly.

14 User Education Users should be educated

about best security practices,
such as password hygiene
and recognizing phishing
attempts.

15 Secure Third-Party Third-party integrations (e.g.,

Integration payment gateways) must be
thoroughly vetted for security
compliance.

16 Secure Mobile Devices If the app is available on

mobile devices, mobile
security measures must be
implemented (e.g.,
encryption, app permissions).

17 Regular Security Audits Periodic security audits and

penetration testing should be
conducted to identify and
address vulnerabilities.

18 User Data Deletion Users should have the option

to delete their accounts and
associated data securely.

19 Secure Emergency Security measures should be

Features implemented for emergency
assistance features to
prevent misuse.

These security requirements serve as a foundation for ensuring the security and privacy of the
Cab Buddy application, protecting both user data and the overall system from potential threats
and vulnerabilities. Specific security requirements may be refined based on the unique
characteristics of your application and its threat landscape.
(e)

(f)

Threat Modeling:

. Data Flow Diagram (DFD):

A Data Flow Diagram is a visual representation of how data flows within a system and
between its components. In the context of threat modeling, a DFD helps in identifying potential
threats by mapping out the data's journey through the system. Here's how you can perform
threat modeling using DFD: -
● Identify Components- Start by identifying the main components of your system. These
might include users, servers, databases, and external systems.
● Define Data Flows- Determine how data moves between these components. For
example, data flows from users to the server during login, from the server to the
database during data retrieval, and so on.
● Identify Trust Boundaries-Mark trust boundaries in the diagram where data transitions
from a less trusted environment to a more trusted one. For example, data from external
users entering the system should be marked as crossing a trust boundary.
 ● Threat Identification-At each step in the data flow, consider potential threats. These
could include data interception, data manipulation, unauthorized access, or data
disclosure.
● Impact Assessment- Assess the impact of each threat. Determine what could go
wrong if a specific threat is realized. For instance, unauthorized access to the database
could lead to data breaches.

Level 0 DFD

Level 1 DFD
Attack Trees:

● Start with the Goal-Define the primary goal of an attacker. For example, the goal
might be to gain unauthorized access to the system.
● Branch into Subgoals- Create branches that represent subgoals or steps an
attacker would take to achieve the primary goal. Each branch is a potential attack
vector.
● Leaves Represent Outcomes- At the end of each branch, identify possible
outcomes or consequences of the attack. These can include data breaches,
service disruption, or unauthorized privilege escalation.
● Assess Attack Complexity- For each branch, assess the complexity or difficulty
of achieving that subgoal. Some may require multiple steps or prerequisites.
● Likelihood and Impact- Consider the likelihood of an attacker following a
specific path and the impact of that path being successful.

STRIDE MODEL

Spoofing Identity (S):

● Threat: Unauthorized users impersonating students or drivers.
● Mitigation: Implement strong user authentication and verification processes.
Tampering with Data (T):
● Threat: Data manipulation during ride-sharing, payment processing, or user
profiles.
● Mitigation: Use encryption to protect data integrity and validate input.
 Repudiation (R):
● Threat: Users denying their actions (e.g., booking a ride).
● Mitigation: Implement audit logs and digital signatures for transaction
confirmation.
Information Disclosure (I):
● Threat: Unauthorized access to user data.
● Mitigation: Apply strict access controls, encryption, and secure APIs.
Denial of Service (D):
● Threat: Attackers disrupting the service (e.g., by overwhelming the application).
● Mitigation: Implement rate limiting, DoS protection, and redundancy.
Elevation of Privilege (E):
● Threat: Unauthorized users gaining admin-like privileges.
● Mitigation: Apply the principle of least privilege and regular security audits.

(g)
The DREAD model is a risk assessment framework that assigns scores to threats based on five
attributes:
1. Damage- The potential damage or harm that a successful exploit of the threat can
cause. Assign a score from 1 (low) to 10 (high).
2. Reproducibility- How easy it is to reproduce the threat. Assign a score from 1 (easy to
reproduce) to 3 (difficult to reproduce).
3. Exploitability- How likely it is that an attacker can exploit the threat. Assign a score
from 1 (unlikely) to 3 (likely).
4. Affected Users- The number of users or resources affected by the threat. Assign a
score from 1 (few users affected) to 3 (many users affected).
5. Discoverability- How easy it is for an attacker to discover and attempt the threat.
Assign a score from 1 (easily discovered) to 3 (difficult to discover).

To rank threats using the DREAD model:

1. Identify each threat that you've discovered through threat modeling.

2. Evaluate each threat's attributes (Damage, Reproducibility, Exploitability, Affected

Users, Discoverability) and assign scores.

3. Calculate a threat's overall risk score by averaging the scores for each attribute (e.g.,
(Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5).

4. Rank threats based on their overall risk scores, with higher scores indicating higher
priority for mitigation.
 Threats:
❖ Unauthorized Access:
➢ Damage: 7
➢ Reproducibility: 6
➢ Exploitability: 7
➢ Affected Users: 8
➢ Discoverability: 6
➢ DREAD Score: (7 + 6 + 7 + 8 + 6) / 5 = 6.8
❖ Data Breaches:
➢ Damage: 9
➢ Reproducibility: 6
➢ Exploitability: 7
➢ Affected Users: 9
➢ Discoverability: 5
➢ DREAD Score: (9 + 6 + 7 + 9 + 5) / 5 = 7.2
❖ Financial Fraud:
➢ Damage: 8
➢ Reproducibility: 6
➢ Exploitability: 7
➢ Affected Users: 7
➢ Discoverability: 6
➢ DREAD Score: (8 + 6 + 7 + 7 + 6) / 5 = 6.8
❖ Malware and Phishing:
➢ Damage: 6
➢ Reproducibility: 8
➢ Exploitability: 8
➢ Affected Users: 6
➢ Discoverability: 7
➢ DREAD Score: (6 + 8 + 8 + 6 + 7) / 5 = 7.0
❖ Denial of Service (DoS) Attacks:
➢ Damage: 7
➢ Reproducibility: 7
➢ Exploitability: 7
➢ Affected Users: 8
➢ Discoverability: 7
➢ DREAD Score: (7 + 7 + 7 + 8 + 7) / 5 = 7.2
❖ API Attacks:
➢ Damage: 7
➢ Reproducibility: 7
➢ Exploitability: 8
➢ Affected Users: 7
➢ Discoverability: 6
➢ DREAD Score: (7 + 7 + 8 + 7 + 6) / 5 = 7.0
❖ Code Exploitation:
 ➢ Damage: 8
➢ Reproducibility: 6
➢ Exploitability: 8
➢ Affected Users: 7
➢ Discoverability: 6
➢ DREAD Score: (8 + 6 + 8 + 7 + 6) / 5 = 7.0
❖ Insider Threats:
➢ Damage: 7
➢ Reproducibility: 5
➢ Exploitability: 6
➢ Affected Users: 7
➢ Discoverability: 6
➢ DREAD Score: (7 + 5 + 6 + 7 + 6) / 5 = 6.2
❖ Privacy Violations:
➢ Damage: 8
➢ Reproducibility: 6
➢ Exploitability: 7
➢ Affected Users: 8
➢ Discoverability: 6
➢ DREAD Score: (8 + 6 + 7 + 8 + 6) / 5 = 7.0
❖ Reputation Damage:
➢ Damage: 9
➢ Reproducibility: 5
➢ Exploitability: 6
➢ Affected Users: 8
➢ Discoverability: 7
➢ DREAD Score: (9 + 5 + 6 + 8 + 7) / 5 = 7.0

Therefore Denial Of Service (DoS) comes up at the highest ranking with the overall score of 7.2