Java Application Security

@arafkarsh arafkarsh
8 Years
Network &
Security
6+ Years
Microservices
Blockchain
8 Years
Cloud
Computing
8 Years
Distributed
Computing
Architecting
& Building Apps
a tech presentorial
Combination of
presentation & tutorial
ARAF KARSH HAMID
Co-Founder / CTO
MetaMagic Global Inc., NJ, USA
@arafkarsh
arafkarsh
1
Java Application
Security
Secure SDLC
DevOps & SRE
Security Controls & DevSecOps
Java Application Vulnerabilities
To Build Cloud Native Apps
Using Composable Enterprise Architecture
Part 14 of 15

View Slide

BPB
Building Cloud
Native Apps
2
Coming Soon….
Section CH Chapter Title Pages Final Pages
Setting the
Context
1. Understanding Cloud Architecture 25 36
2. Architecture Styles & Patterns 25 48
Specifications 3. Design Thinking, Lean Startup & Agile 15 30
4. Epics, User Stories, MVP, and Releases 25 29
Design Patterns 5. Domain-Driven Design 35 40
6. Event Sourcing & CQRS 25 35
7. Monolith Migration Patterns 25 35
8. Microservices Patterns 35 40
Development
Strategies
9. Microservices with Java and Springboot 35 40
10 Microservices Testing Strategies 35 40
11. Infra Code - Container & Kubernetes 35 35
12 Security & Service Mesh 25 40
Deployment
Process
13 Build Pipelines and CI/CD 10 15
14 Observability in Microservices 10 10
15 DevOps 10 15
16 DevSecOps 10 15
Total 380 503

View Slide

@arafkarsh arafkarsh 3
Secure SDLC
NIST Secure SDF / SANS Cloud Architecture
Security Quality Assurance / SQUARE Framework
Secure Design Patterns / Threat Modeling
Enterprise Security, Zero Trust, SDN, SDP
1
Secure SDLC
Security Policies / Kubernetes Policies
Service Mesh / Server Hardening
(Linux, Apache, Tomcat, PostgreSQL,
Mongo, MySQL, Redis)
2
DevOps & SRE
DevOps Lean Thinking, SAST / DAST
5 Principles of DevOps / CALMS Framework
SRE Implements DevOps / Shift Left
Infrastructure as a Code / Observability
3
Security Controls & Ops
Application Security Controls
Generic Controls
HIPAA / PCI Controls
DevSecOps
4
Java Code Vulnerabilities
Cross-Site Scripting Vulnerability (XSS)
Buffer Overflow Exploit
Directory Traversal Exploit
Command / Shell Injection Exploit
Vulnerable and Outdated Components
HTTP Response Split Vulnerability
5
Parameter Manipulation Vulnerability
SQL Injection Vulnerability
XML Entity Injection / (XXE) Attack
XPath Injection Attack
Cross-Site Request Forgery (CSRF)
Server-Side Request Forgery (SSRF)
6

View Slide

0
Setting the Context
o Threats, Vulnerabilities & Defense
o Secure SDLC
o Modernizing Journey
o Case Study: Health Care App
4

View Slide

Threats,
Vulnerabilities
& Defense

View Slide

Management
Pipeline Automation
Architecture
SpecOps Workflow – Secure SDLC
6
Green
Field
Brown
Field
Domain Driven Design
Event Sourcing / CQRS
Migration Patterns
Strangler Fig, CDC…
Build
Design Develop Test Stage Ops
Cloud
• Fault Tolerance
• Reliability
• Scalability
• Traffic Routing
• Security
• Policies
• Observability
• Unit Testing
• Component
• Integration
• Contract
• SAST
• DAST
• Package
Repositories
• Mvn, npm,
docker hub
• Infrastructure
• Containers
• Orchestration
• Serverless
• Traffic Routing
• Security (mTLS, JWT)
• Policies (Network / Security)
• Observability
Infra Code
• Feature
Code
• Configs
Source Code
Specs

View Slide

Modernization Journey towards Cloud Native Apps
7
Source:
Page 16
US DoD Enterprise
DevSecOps 2.0
Fundamentals

View Slide

What exactly
is a
Minimum
Viable
Product?
8
Let us understand this with a case study on eCommerce Shopping Portal.

View Slide

Example: Healthcare App
9
Theme / Initiative Epic User Story Sprint
Healthcare / We Care
1. Patient
2. Healthcare Staff
3. Appointments
4. Diagnosis
5. Lab
6. Pharmacy
7. Auth
4. Diagnosis
Release 1
1. Pre-Checkup
2. Search Medical
History
3. Diagnosis &
Prescription
Release 2
1. Prescribe for Lab
Tests
Stories
1. Pre-Checkup
2. Search Medical
History
3. Diagnosis &
Prescription
4. Prescribe for Lab
Tests

View Slide

User Journey with Story Map & Release Cycles
10
1. Register 3. Make Appointment 4. Diagnosis and Prescription 6. Get Medicine
5. Lab Tests
Health Staff Appointment Pharmacy
Lab
Diagnosis
2. Search & Select Doctor
Patient
User Journey
Minimum Viable Product
Upload Medical
Docs
Add Doctor / Nurse
Cancel
Appointment
R2 Lab Tests
View Medical
History
Duty Calendar
R3 Reschedule
Register Search Doctor
Available Dates
Book Appointment Medical History
Check
Verify
Prescription
Pack
Medicines
R1
Pre-Checkup
Diagnosis &
Prescription
Appointment
Upload
Results
Schedule Duty Time
Make
Payment
Share Medical
Docs
R4 Appointment
Calendar
Make
Payment
View
Appointments
Email
SMS

View Slide

Data Flow Diagram – L0 / System Context Diagram
11
• System Context Diagram
or Level 0.
• An abstraction view
• Shows the system as a
single process with its
relationship to external
entities.
• It represents the entire
system as a single bubble
with input and output
data indicated by
incoming/outgoing
arrows.

View Slide

Data Flow Diagram – L1
12
• The L0 Context
diagram is
decomposed into
multiple bubbles /
processes.
• Highlight the
system's primary
functions and
• Break down the
high-level process of
0-level DFD into
subprocesses.

View Slide

Data Flow Diagram – L2
13
• The L1 Data Flow
Diagram is
decomposed into
multiple bubbles /
processes.
• Highlights the
details of that
Specific Business
Process.
• It also shows the
data stores
associated with that
Sub Process.

View Slide


View Slide

1
Secure SDLC
15

View Slide

Security
o NIST: Secure Software Development Framework
o Cloud Security Architecture
o SANS Cloud Security Architecture & Principles
16

View Slide

17
CASB: Cloud Access Security Broker
SIEM: Security Information Event Management
SOAR: Security Orchestration, Automation, and Response
XDR: Extended Detection and Response
MDR: Managed Detection and Response
NDR: Network Detection and Response
PTaaS: Penetration Testing as a Service
ITDR: Integrated Threat Defense Response

View Slide

NIST
Secure Software Development Framework
o Prepare the Organization
o Protect the Software
o Produce Well-Secured Software
o Respond to Vulnerability Reports
18

View Slide

NIST: Secure Software Development Framework
19
1. Prepare the Organization: This includes providing necessary training, establishing an
incident response team, defining security roles and responsibilities, and identifying
security requirements.
2. Protect the Software: It covers how to manage the security risks in the software, which
includes conducting threat modeling, using approved tools, libraries, and frameworks,
securing your environments, and implementing secure coding practices.
3. Produce Well-Secured Software: This involves properly implementing security practices
during the software development process. It includes performing security testing,
conducting code reviews, managing external software components, and creating a secure
software bill of materials.
4. Respond to Vulnerability Reports: The organization must respond effectively if a
vulnerability is found in the software. This includes managing vulnerability reports, fixing
known vulnerabilities, and communicating with stakeholders.

View Slide

SSDF: Prepare the Organization
20
1. Training: Develop and deliver training to software developers, security teams, and other
relevant personnel on secure software development practices. This could include secure
coding techniques, threat modeling, using security tools, and understanding common
vulnerabilities.
2. Incident Response Team: Form a cross-functional team responsible for responding to
security incidents. This team should be trained in incident response procedures and
have clear roles and responsibilities.
3. Define Roles & Responsibilities: Establish clear roles and responsibilities related to
security within the software development process. This could include identifying who is
responsible for carrying out security testing, who handles security incidents, and who
makes decisions about risk acceptance.
4. Security Requirements: Establish a process for identifying and documenting security
requirements for each software project. These requirements should be informed by
business needs, regulatory requirements, and threat modeling activities.

View Slide

SSDF: Protect the Software
21
1. Threat Modeling: Carry out threat modeling activities during the design phase of
software development. This should include identifying potential threats,
assessing their potential impact, and designing controls to mitigate them.
2. Use of Approved Tools, Libraries & Frameworks: Define a list of approved
development tools, libraries, and frameworks known to be secure. Developers
should be encouraged to use these whenever possible and avoid using unvetted
third-party components.
3. Secure Environments: Implement controls to secure the environments in which
software is developed and tested. This could include network security controls,
access controls, and the secure configuration of development tools and servers.
4. Secure Coding Practices: Implement a set of secure coding standards and
practices, and ensure that developers are trained. This could include practices to
prevent common vulnerabilities such as injection attacks, cross-site scripting
(XSS), and insecure direct object references (IDOR).

View Slide

SSDF: Produce Well-Secured Software
22
1. Security Testing: Implement a robust security testing program. This should
include a combination of automated and manual testing techniques and cover
functional and non-functional security requirements.
2. Code Reviews: Conduct regular code reviews focusing on identifying potential
security issues. Ideally, This should be done by someone other than the code’s
author.
3. Manage External Software Components: Implement a process for managing the
use of external software components. This should include tracking which
components are used, assessing them for security vulnerabilities, and ensuring
they are up-to-date.
4. Secure Software Bill of Materials: Create a secure software bill of materials
(SBOM) for each software product. This should list all of the components used in
the software, along with details of their version and patch status.

View Slide

SSDF: Respond to Vulnerability Reports
23
1. Vulnerability Management: Implement a process for handling reports of
vulnerabilities in your software. This should include a method for users to report
vulnerabilities, a process for validating and prioritizing these reports, and a
process for remediation.
2. Remediation: Ensure a process is in place to remediate identified vulnerabilities
quickly. This might involve patching the software, implementing a workaround,
or accepting the risk based on a business decision.
3. Communication: Develop a communication plan to inform stakeholders about
security issues. This might involve notifying users about security vulnerabilities,
informing them about available patches, or advising them on mitigating risks.

View Slide

SANS
Cloud Security Architecture Principles
24

View Slide

SANS Cloud Security Architecture Principles
25
Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute
Think
Components
Design for
Failure
Always
Think of
Feedback Loops
Use Different
Storages
Options
Built-In
Security
at every Layer
CENTRALIZATION
Focus on
Centralization
Standards & Automation
Design for
Elasticity

View Slide

Built-In Security At Every Layer
26
Built-In
Security
at every Layer
• Cloud Architecture is composed of Multiple
Layers. From a Cloud Native App perspective
Each Microservice is specific layer in the
Application Stack.
• Each Layer must be self defending.
• Each Layer Must have a Security Layer to be part
of Defense in Depth.
• Depends on the Security Guidelines / Policies
some of the security measures will be internal
some external.

View Slide

27
Stack Layer Controls
1 Data
Backup, Data Leak Prevention, Encryption in Transit
and Rest.
2
Application Logic +
Presentation
Web App Firewall, Secure Web Gateway, Identity &
Access Management, Scans / Pen Tests, Service Mesh
Policies
3 Network
Access Controls, Firewalls, Service Mesh, Routing,
DDoS Defense
4 Operating Systems
Backups, Configuration, Vulnerability Scanning, User /
Privilege Management
5 Hypervisor
Configuration, Access Controls, User / Privilege
Management
Built-In
Security
at every Layer

View Slide

28
Built-In
Security
at every Layer
o Cloud introduced very frequent changes to the environment
(Infrastructure / Software)
o Security Measures must be embedded for these Rapid changes.
1. Defining Security in the Code (Functional Code, Security
Policies)
2. Include Security Configuration Params for the Container /
Virtual Machines
3. Automating Security Processes & Activities
4. Building Continuously Monitored Environments
o Many of these are realized through Sound DevSecOps Practices.

View Slide

Think ”Components”
29
Think
Components
o From Systems to Component based thinking is a Major shift
for Security Professionals
o Cloud is more oriented towards component-based model
and linked together based on Business requirements
o Key aspects of Component is – Reusability
o Network Policies
o Security Policies
§ The above can be applied across multiple clouds
§ Ex. Terraform, Kubernetes, Service Mesh

View Slide

Design for Failure
30
Design for
Failure
o In the Cloud Failure is common
o Elasticity Issues
o Configuration Issues
o Cloud Provider Issues
o Chaos Engineering plays a big Role in Preparing for this
o Product ion – Network Testing
o Production – Security Testing
o Production – Performance Testing
Minimize
Blast Radius
Chaos Engineering
Principle

View Slide

Design for Elasticity
31
o Microservices, Containers and Kubernetes brought automated dynamic
scaling up and down of the systems (containers)
o This is a new environment from Security Perspective compared with old
Static environment (Changes are periodic and planned).
o Designing Elasticity from Security Perspective
o Vertical or Horizontal Scaling
o What thresholds are appropriate for scaling up & down
o How will inventory management adjust to system volume changes
o Images new systems are spawned from
o Where are new systems located in the network
o Host Based Security + Licensing
Design for
Elasticity

View Slide

Make use of Different Storage Options
32
Use Different
Storages
Options
o There are many types of Storage options available in Cloud and
each has its own security features.
o Design the Data Security based on the storage options.
o Things to consider and evaluate
o Storage have appropriate SLA
o Storage options for Dev and Ops
o Storage have adequate Redundancy & Archival
o Storage have native encryption capabilities
o Storage have adequate logging and event generation

View Slide

Always think of Feedback Loops
33
o One of the most critical Principle is Feedback Loops
o One of the critical aspect of Feedback loops is Logging
o Enable Logging everywhere you can
o Within the entire cloud environment (Cloud Trail –Azure,
Cloud Watch – AWS, Stack Driver – Google)
o OS Types, Network Platforms
o For All Identity & Access Management
o For all Interconnected services and their activity
o Feedback Loops = Logging
o Secure Log Access
Always
Think of
Feedback Loops

View Slide

Focus on Centralization, Standards, Automation
34
o Centralization – Having a Single Glass of Pane to see all the things
happening in the cloud.
o Using the Same vendor Products across all the environments (Cloud,
On-Premise) – If Possible
o Standardization – Go with well known standards
o SAML and OpenID – Connect for IAM
o YAML for Configs / Infra as Code
o AES-256+ for Crypto
o Automation – Is the Key for DevOps and DevSecOps. Manual efforts
are doomed to fail due to rapid changes.
CENTRALIZATION
Focus on
Centralization
Standards & Automation

View Slide

Blast Radius
35
o One of the Core Security Concepts in the world of DevOps & Cloud
Computing is the Blast Radius
o It’s the amount of damage that could be caused if something goes
wrong
o An Account or Server gets hacked
o A Component Fails
o Design the Security Model in such a way that the damage is limited
to that area or Service.
o In Microservices architecture link this concept with Circuit Breakers,
Bulkhead Design Patterns.

View Slide

Security Quality Assurance
36

View Slide

SQA – 7 Steps
37
1. Security Requirements Analysis: One of the first steps in SQA is defining and
understanding the security requirements of the software. This includes
identifying potential threats, specifying security objectives, and defining the
necessary security controls. Tools such as threat modeling, risk assessments, and
the SQUARE methodology can be used in this phase.
2. Secure Design and Coding Practices: The SQA process emphasizes the
importance of security from the earliest stages of software development. This
involves following secure coding practices to prevent common vulnerabilities
and adhering to a secure software design emphasizing principles such as least
privilege, defense in depth, and secure defaults.
3. Security Testing: This involves various types of testing, such as static application
security testing (SAST), dynamic application security testing (DAST), and
penetration testing, to identify potential vulnerabilities in the software. Security
testing should be conducted regularly throughout the SDLC.

View Slide

SQA – 7 Steps
38
4. Code Reviews and Audits: Regular code reviews by peers or automated tools can help catch
potential security issues early. Audits, often conducted by independent third parties, can
assess the software's overall security and identify improvement areas.
5. Incident Response and Management: Despite all precautions, incidents may still occur. SQA
involves having an incident response plan to handle security incidents efficiently and
effectively. This includes procedures for identifying, containing, eradicating, and recovering
from incidents and post-incident reviews to learn from the incident.
6. Continuous Monitoring and Improvement: SQA is not a one-time activity but a continuous
process that involves monitoring the software for potential security issues and continually
improving the security controls based on the feedback received. This includes staying up-to-
date with the latest security trends and adjusting the security measures accordingly.
7. Training and Awareness: It’s essential to ensure that all team members involved in the
software development process know the importance of security and are trained in secure
development practices. This can significantly reduce the chance of security issues arising
due to human error or oversight.

View Slide

Software Quality Assurance
39
Quality Model
This component defines a hierarchical structure of quality characteristics and sub-characteristics that
help to identify, describe, and measure various aspects of software quality. Examples of quality
characteristics include functionality, reliability, usability, efficiency, maintainability, and portability.
Quality Requirements:
Quality requirements are derived from the quality model and describe the desired level of quality for
a specific software system. These requirements are typically specified as part of the system
requirements and may include qualitative and quantitative measures.
Quality Evaluation
This component assesses the degree to which a software system meets its quality requirements. Quality
evaluation may involve various techniques, such as testing, inspection, and analysis, to identify potential
issues and determine whether the system satisfies the defined quality criteria.
Quality Management
Quality management involves planning, organizing, and monitoring the activities related to quality
requirements engineering to ensure that the software system meets its quality goals. This component
encompasses the entire software development lifecycle, from initial requirements analysis to post-
deployment maintenance.
You will find similar concepts in ISO/IEC 27001 a
standard for Information Security Management Systems

View Slide

Quality Requirements
40
Translate the identified quality characteristics into specific, measurable
quality requirements for the healthcare app. Some examples may
include:
1. The app must be compliant with HIPAA and other relevant data
privacy regulations.
2. The app should have a 99.9% uptime, with a maximum of 5 minutes
of unplanned downtime per month.
3. The average response time for search queries should be at most 2
seconds.
4. The app must be compatible with the latest iOS and Android
versions and popular web browsers.

View Slide

Quality Model
41
First, identify the relevant quality characteristics and sub-characteristics for the healthcare
app. Some examples may include:
1. Functionality: accuracy of medical information, ease of data entry, interoperability with
other healthcare systems, and data privacy compliance.
2. Reliability: system availability, fault tolerance, and data backup/recovery.
3. Usability: user-friendly interfaces for patients, doctors, nurses, and pharmacists;
accessibility features for users with disabilities; and multilingual support.
4. Efficiency: fast response times for search queries, minimal resource usage, and
optimized data storage.
5. Maintainability: modularity of code, ease of updating medical information, and efficient
bug fixing.
6. Portability: compatibility with various devices and operating systems, easy integration
with other healthcare software, and support for future technology advancements.

View Slide

Quality Evaluation
42
Design and implement evaluation processes to assess the healthcare app's
compliance with the defined quality requirements. These processes may
include:
1. Conducting user testing with patients, doctors, nurses, and pharmacists to
evaluate usability and identify potential improvements.
2. Performing automated and manual testing to identify and address
functionality issues, security vulnerabilities, and performance bottlenecks.
3. Monitoring system performance and resource usage to ensure compliance
with efficiency requirements.
4. Conducting code reviews and using static code analysis tools to assess
maintainability and adherence to coding standards.

View Slide

Quality Management
43
Develop a quality management plan for the healthcare app to ensure continuous
quality improvement throughout the development process. This may involve:
1. Establish a cross-functional quality team to oversee quality-related activities,
including development, testing, and user experience team representatives.
2. Setting up a quality assurance process, including regular reviews of requirements,
design, code, and testing artifacts.
3. Implementing a continuous integration and deployment pipeline to ensure rapid
feedback on potential quality issues.
4. Defining clear roles and responsibilities for quality-related tasks and providing
relevant training to team members.
5. Monitoring and reviewing quality metrics and using them to guide ongoing
improvements to the healthcare app.

View Slide

SQuaRE Framework
Security Quality Requirements Engineering
o 9 Steps of SQUARE Framework
44

View Slide

9 Steps in SQUARE
45
1. Agree on definitions: This is the initial step where project stakeholders agree on definitions for security
concepts that will be used throughout the project.
2. Identify security goals: The stakeholders identify high-level security objectives for the software product.
3. Develop artifacts to support security requirements definition: The team develops supporting materials
(e.g., system diagrams, data flow diagrams) that will help in the identification of security requirements.
4. Perform risk assessment: This step involves identifying potential security risks and their impacts and using
this information to prioritize security goals and requirements.
5. Select elicitation techniques: The team selects techniques for gathering security requirements based on
the project’s specific context and constraints.
6. Elicit security requirements: The team uses the selected techniques to gather security requirements from
various sources, such as stakeholders and existing documentation.
7. Categorize requirements: The gathered requirements are categorized (e.g., by priority, by the security goal
they support) to aid in their analysis.
8. Prioritize security requirements: The team prioritizes the security requirements based on factors like risk
level, cost of implementation, and stakeholder value.
9. Inspect requirements: The team reviews the requirements for completeness, consistency, and other quality
factors. This step may lead to further refinement of the requirements.

View Slide

46
1. Agree on definitions: In this step, all the stakeholders agree on the common
security terminologies to avoid confusion in later stages.
For example, "Data breach" might be defined as "an incident in which
unauthorized individuals access sensitive, protected health information."
2. Identify security goals: The stakeholders identify high-level security objectives
for the app.
For example, a major security goal could be to "ensure the confidentiality,
integrity, and availability of patient health information."
3. Develop artifacts to support security requirements definition: This could
include creating a system architecture diagram that shows how patient data
flows through the app, or a list of potential actors who could interact with the
app, such as patients, healthcare providers, system administrators, etc.

View Slide

47
4. Perform risk assessment: Identify the potential threats and risks to the app.
For example, unauthorized access to patient health records, data corruption,
system downtime. Once identified, assess the potential impact of each risk and
their likelihood of occurrence.
5. Select elicitation techniques: Determine the best techniques to gather the security
requirements.
This could include interviewing stakeholders, reviewing regulatory requirements
(like HIPAA in the United States), or conducting threat modeling exercises.
6. Elicit security requirements: Gather the specific security requirements using the
techniques selected in the previous step.
For example, "The system shall authenticate users before granting access to
patient health information", or "The system shall encrypt patient health
information at rest and in transit."

View Slide

48
7. Categorize requirements: Group the gathered requirements based on their
categories.
For example, requirements might be grouped into categories like "Authentication",
"Data Integrity", "Confidentiality", "Availability", etc.
8. Prioritize security requirements: Based on factors such as risk level, regulatory
importance, cost of implementation, and stakeholder value, prioritize the
requirements.
For example, "Implementing two-factor authentication for all users" might be
considered a high-priority requirement due to its importance for data confidentiality.
9. Inspect requirements: Review the requirements for completeness, consistency, and
other quality factors.
For instance, check if there are any conflicting requirements, or if any security goals
have been overlooked.

View Slide

Secure Design Patterns
1. Least Privilege Principle
2. Defense-in-Depth
3. Input Validation & Sanitation
4. Secure By Default
5. Principle of Least Astonishment
49
6. Secure Failure
7. Separation of Duties
8. Secure Data Storage & Transmission
9. Regular Security Updates & Patching
10. Security Monitoring & Auditing

View Slide

50
Least Privilege Principle
Ensure that users and system components have the minimum permissions necessary to perform
their tasks. This limits the potential damage from security breaches and helps maintain the privacy
and integrity of sensitive healthcare data.
Defense-in-Depth:
Implement multiple layers of security controls throughout the application to reduce the likelihood of
a single point of failure. This may include network firewalls, secure communication protocols, strong
authentication and authorization mechanisms, and intrusion detection systems.
Example: Doctors, nurses, patients, and pharmacists in the healthcare app should have different
access levels to medical records and other sensitive data. A nurse might have access to view a
patient's medical history but not modify it. A pharmacist would only have access to a patient's
prescriptions, not their entire medical record.
Example: The healthcare app could employ multiple security layers, such as using a web application
firewall to filter incoming traffic, encrypting data with HTTPS during transmission, and implementing
two-factor authentication for user accounts to reduce unauthorized access.

View Slide

51
Input Validation and Sanitization
Validate and sanitize all user inputs to prevent security vulnerabilities like SQL injection, cross-site
scripting, and buffer overflow attacks. Use strict validation rules, whitelist-allowed input values, and
employ output encoding when displaying user-generated content.
Secure by Default
Design the healthcare app to be secure out of the box, with the most restrictive security settings
enabled by default. Users should explicitly opt out of security features or choose to lower their
security settings.
Example: When a doctor enters a prescription, the app should validate the input to ensure it only
contains valid characters and adheres to proper prescription format. This prevents potential attacks,
like SQL injection, by rejecting or sanitizing malicious inputs.
Example: The healthcare app should have all its security features enabled upon installation, such as
encrypted data storage, strong password requirements, and strict access controls. Users should be
explicitly informed if they decide to disable or modify these default settings.

View Slide

52
Principle of Least Astonishment
Design the app's user interface and functionality to be clear and predictable, minimizing the
likelihood of users making security-related mistakes. For example, ensure that privacy settings are
easily understood and that users are aware of the implications of sharing their healthcare data.
Secure Failure
Ensure that the app fails securely in the event of an error or security breach. This may involve
implementing robust error handling, logging, and monitoring mechanisms to detect and respond to
security incidents.
Example: The app's privacy settings should be clearly labeled, with explanations of how data
sharing options affect user privacy. If a patient opts to share their medical history with a new
doctor, the app should provide a clear indication of what information will be shared and with
whom.
Example: If the healthcare app encounters an error while processing a patient's medical record, it
should not reveal sensitive information in error messages. Instead, it should log the error and notify
the appropriate administrators while presenting a generic error message to the user.

View Slide

53
Separation of Duties:
Separate critical functions of the app, such as data access, system administration, and audit logging,
among different roles or components. This helps prevent unauthorized access to sensitive data and
reduces the risk of insider threats.
Secure Data Storage and Transmission
Encrypt sensitive healthcare data both at rest and in transit using strong cryptographic algorithms
and protocols. Implement proper key management practices to protect encryption keys and ensure
data privacy and integrity.
Example: The app's administrative functions could be divided into separate roles. One role may
manage user accounts, while another role is responsible for database administration. By separating
these duties, it becomes more difficult for a single malicious actor to compromise the entire
system.
Example: The healthcare app could use end-to-end encryption to protect sensitive data, such as
patient records and prescriptions, both in storage and during transmission. This ensures that only
authorized users can access the data, even if it's intercepted by a third party.

View Slide

54
Regular Security Updates and Patch Management
Keep the healthcare app up to date with the latest security patches and updates. Establish a process
for monitoring, assessing, and applying security updates in a timely manner to reduce the risk of
known vulnerabilities being exploited.
Security Monitoring and Auditing:
Implement continuous monitoring and auditing mechanisms to detect and respond to security
events. Regularly review logs and audit trails to identify potential security issues, and use this
information to inform ongoing improvements to the app's security posture.
Example: The development team should have a process in place for regularly checking for security
updates to the app's dependencies and applying patches as needed. Additionally, the team should
be proactive in addressing newly discovered vulnerabilities and releasing updates to users promptly.
Example: The healthcare app could use a combination of intrusion detection systems and security
information and event management (SIEM) tools to monitor for suspicious activity. Regular audits of
user access logs and system events can help identify potential security issues, such as unauthorized
access to sensitive data or attempts to exploit known vulnerabilities.

View Slide

Threat Modeling
1. Identify Assets
2. Create an Architecture overview
3. Identify Potential Threats
4. Prioritize Threats
55
5. Define Mitigation Strategies
6. Validate and Iterate
7. Integrate into Development Process

View Slide

Threat Modeling
56
Identify assets
Determine the critical assets in the healthcare app that need protection. These may include patient
records, medical histories, prescription information, and billing data.
Create an architectural overview
Develop a high-level representation of the app's architecture, including components, data flows,
and interactions with external systems. This overview will help in understanding potential attack
vectors and entry points for attackers.
Identify potential threats
Analyze the architectural overview to identify possible threats and attack scenarios. Common
threat sources in a healthcare app may include unauthorized access to patient data, data
tampering, man-in-the-middle attacks, and denial of service attacks. Threat modeling frameworks,
such as STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and
Elevation of Privilege), can be used to categorize and systematically identify potential threats.

View Slide

Threat Modeling
57
Define mitigation strategies
For each high-priority threat, devise countermeasures to mitigate the risk. These strategies include
implementing secure design patterns, applying security best practices, and adopting relevant security
technologies.
Validate and iterate
Validate the effectiveness of the proposed countermeasures by revisiting the threat model and
analyzing how the mitigations address the identified threats. Threat modeling should be an iterative
process, evolving alongside the app's development to continuously identify and address new threats
Integrate into the development process.
Incorporate threat modeling into the development process, making it an integral part of the
requirements gathering, design, implementation, and testing phases. This ensures that security is
considered throughout the app's lifecycle, resulting in a more secure and robust healthcare
application.
Prioritize threats
Rank the identified threats based on their likelihood and potential impact on the healthcare app.
This step helps in focusing resources on the most critical threats. The DREAD (Damage,
Reproducibility, Exploitability, Affected Users, and Discoverability) model is one of the methods
used to prioritize threats by assigning a numerical score to each threat.

View Slide

Popular Threat Modeling Standards
58
STRIDE
Developed by Microsoft, STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information
Disclosure, Denial of Service, and Elevation of Privilege. It categorizes threats into these six types
and is often used in the context of software development and application security.
PASTA (Process for Attack Simulation and Threat Analysis)
PASTA is a risk-centric threat modeling methodology that simulates potential attacks and analyzes
their impact on the system. It involves seven stages, starting from defining objectives and scoping
the threat model to analyzing and prioritizing threats.
Trike
Trike is a threat modeling methodology focusing on a system's data assets and evaluating the risks
associated with data access, modification, or disclosure. It uses a risk management approach to
identify and prioritize threats based on their potential impact on the system's assets.
S
P
T

View Slide

Popular Threat Modeling Standards
59
CVSS (Common Vulnerability Scoring System)
CVSS is a widely adopted standard for assessing the severity of software vulnerabilities. It provides a
numerical score and a qualitative rating to help organizations prioritize vulnerabilities based on their
impact, exploitability, and other factors.
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)
Developed by CERT/CC, OCTAVE is a risk-based strategic assessment and planning methodology for
organizations to identify and manage their most critical risks.
C
O

View Slide

STRIDE: Health Care App
60
Spoofing:
Spoofing threats involve an attacker impersonating a legitimate user,
system, or service to gain unauthorized access to sensitive information or
perform malicious actions.
Example: An attacker could impersonate a patient or a healthcare provider
to access sensitive medical records or modify patient data.
Mitigations:
• Implement strong authentication mechanisms, such as multi-factor
authentication (MFA) and password policies, to prevent unauthorized
access.
• Use digital certificates and secure communication channels (e.g., HTTPS)
to ensure the authenticity of the app and its components.

View Slide

61
Tampering
Tampering threats involve unauthorized modification of data, code, or
system configurations.
Example: An attacker could tamper with the healthcare app's code,
introducing a backdoor or modifying the data stored in the database.
Mitigations:
• Use secure coding practices and perform regular code reviews and
security testing to detect vulnerabilities.
• Apply cryptographic techniques, such as digital signatures or hashes, to
ensure the integrity of data and code.
• Use access controls and secure database configurations to prevent
unauthorized data modifications.

View Slide

62
Repudiation:
Repudiation threats involve an attacker performing malicious actions
without the possibility of being traced or held accountable.
Example: A malicious healthcare provider could alter a patient's medical
record without leaving any trace of the modification.
Mitigations:
• Implement comprehensive logging and auditing mechanisms to track
user actions and system events.
• Use digital signatures and non-repudiation techniques to ensure the
authenticity and integrity of user actions.
• Regularly review logs and monitor for suspicious activity.

View Slide

63
Information Disclosure:
Information disclosure threats involve unauthorized access or exposure
of sensitive data.
Example: An attacker could exploit a vulnerability in the healthcare app
to access and leak patients' medical records.
Mitigations:
• Encrypt sensitive data in transit (e.g., using HTTPS) and at rest (e.g.,
using encryption algorithms like AES).
• Use access controls and role-based access control (RBAC) to limit
access to sensitive information.
• Perform regular security testing and vulnerability assessments to
detect and fix potential vulnerabilities.

View Slide

64
Denial of Service (DoS):
DoS threats involve making the healthcare app or its services unavailable
to legitimate users, disrupting normal operations.
Example: An attacker could flood the healthcare app's server with traffic,
overwhelming its resources and causing it to crash.
Mitigations:
• Implement rate-limiting and traffic management techniques to
mitigate the impact of DoS attacks.
• Use redundancy and load balancing to ensure the app's availability
and resilience.
• Monitor and analyze traffic patterns to detect and respond to
potential DoS attacks.

View Slide

65
Elevation of Privilege:
Elevation of privilege threats involves attackers gaining higher privileges within
the system, allowing them to perform unauthorized actions.
Example: An attacker could exploit a vulnerability in the healthcare app to
escalate their privileges and access sensitive data or functionalities reserved
for administrators.
Mitigations:
• Follow the principle of least privilege, ensuring users and applications have
only the minimum necessary permissions.
• Regularly review and update user permissions and roles.
• Perform security testing and vulnerability assessments to detect and fix
potential privilege escalation vulnerabilities.

View Slide

Security on Enterprise
o 802.1x EAP Security
o Port Knocking & SPA – Single Packet Authorization
o Micro Segmentation / Software Defined Firewall
o Zero Trust and VPNs
o Service Mesh
66

View Slide

IEEE 802.1x Wired / Wireless
67
Source: What is 802.1X? How Does it Work? https://www.securew2.com/solutions/802-1x
https://standards.ieee.org/ieee/802.1X/7345/
• 802.1X is an authentication protocol to allow access to networks with the use of a RADIUS server.
• 802.1X and RADIUS based security is considered the gold standard to secure wireless and wired networks.
An 802.1X network is different from home networks in one major way;
1. it has an authentication server called a RADIUS Server.
2. It checks a user's credentials to see if they are an active member of the organization &
3. depending on the network policies, grants users varying levels of access to the network.
This allows unique credentials or certificates to be used per user, eliminating the reliance
on a single network password that can be easily stolen

View Slide

802.1x EAP Security
68
• Standard Authentication protocol used on encrypted networks is Extensible Authentication Protocol (EAP).
• 802.1X is the standard that is used for passing EAP over wired and wireless Local Area Networks (LAN).
• It provides an encrypted EAP tunnel that prevents outside users from intercepting information.
The EAP protocol can be configured
1. Credential (EAP-TTLS/PAP and PEAP-MSCHAPv2) and
2. Digital Certificate (EAP-TLS) authentication and is a highly secure method for protecting the authentication
process.
Source: What is 802.1X? How Does it Work? https://www.securew2.com/solutions/802-1x
802.1X only includes 4
major components:
1. Client
2. Access-point/switch
3. RADIUS Server
4. Identity provider

View Slide

Port Knocking
69
• Port knocking is a simple method to grant remote access without leaving a port
constantly open.
• In the following config of KnockD – the Port (8888) will be open for 10 seconds
based on the correct sequence of access on ports – 7000, 8000, 9000.
Source: Ubuntu Port Knocking Manual: https://help.ubuntu.com/community/PortKnocking
Security by Obscurity

View Slide

32 Bit
64 Bit
32 Bit
Single Packet Authorization
70
UID OTP
Counter GMAC
128 Bit
SPA = UID, CTR OTP, GMAC
UID Universal ID of SDP Client
CTR Hashed with seed to Create OTP
OTP One Time Password: HTOP
GMAC Signature of UID, CTR, OTP
Seed Shared Secret for OTP
Encryption
Key
Shared Key for GMAC
(AES-256)
OTP HMAC [Seed + CTR]
GMAC E-Key [UID + OTP + CTR]
CTR
Is incremented to mitigate
playback attacks
= 256
SPA addresses all the limitations of Port Knocking
By Default, SPA Gateway Drops All the Packets
1. Client Sends a SPA Packet
2. Gateway Receives the Packet and Decrypts Packet
3. Validates the Credentials based on protocol / port
4. If Valid, then Adds a Firewall rule to open an mTLS
Connection
5. Once the Connection is established the Gateway
removes the firewall rule making the service go Dark
Again.
o The established mTLS session will not be affected by
removing the firewall rule.

View Slide

Single Packet Authorization: Benefits
71
ü SPA Blackens the Gateway and all the services Behind
the Gateway are invisible to the world.
ü SPA also mitigates DDoS attacks on TLS. SDP Gateway
discards the TLS DoS attack before it gets into the
handshake.
ü The First packet to the Gateway must be a SPA
Packet. Any other packet will be viewed as an Attack
this helps in attack detection.
Source: https://network-insight.net/2019/06/zero-trust-single-packet-authorization-passive-authorization/

View Slide

Perimeter Security Vs. Zero Trust
72
Classic Security Model
Perimeter Security
• Location Based (External /
Internal)
• Anyone inside the network is
always trusted.
• Based on Layered Security
Never Trust,
Always Verify
1
Implement
Least Privilege
2
(Always)
Assume Breach
3
Forrester's John Kindervag 2010: No More Chewy Centers: Introducing
The Zero Trust Model Of Information Security
Inspired from Jericho Forum Commandments v1.2 May 2007
Source: Microsoft: Jericho & Modern Security
Restrict everything to a secure Network
Zero Trust
Protect Assets
anywhere with
Central Policy

View Slide

Zero Trust: Access Management
73
• Least Privilege
• Every Access is limited to a
specific user, device, and
app or resource only
• Centralized
• Policies are centralized
across common IT Systems
• Policies are defined by
Business Team (Support
from IT)
Source: RSA Conference. Mar 17, 2019: Fallacy of Zero Trust Network By Paul Simmonds
• Dynamic
• Access Decisions are made
in real-time
• Context of the Access
influence the Decision
• Adaptive
• Open to Support new Auth
Protocols
• Constantly Evolving System
(Machine Learning, AI)

View Slide

Zero Trust: Data
74
• Adopt the Principle of Least Privilege
• Access to the Data MUST be limited to a Specific user, device
and App or Resource Only
• Identify the User Persona and limit the access based on that
• Contextual Access Control
• Data Access Policies must be defined by the Business with the support of IT
• Access decisions must be made in real-time – as and when its required.
• Operate Outside your Control
• Business needs to interact with the outside world

View Slide

Zero Trust: Network
75
• It’s Application and User Centric and not Infra or Technology Centric
• No DMZ or VPN anymore: No Security Perimeter
• All Network Sessions MUST have Authentication and Authorization
• Only Secure (Encrypted) Protocols allowed on Network
• More than One way to Implement Zero Trust Network
• Network Micro Segmentation (Lots of Tiny Firewalls)
• Software Defined Perimeter (Lots of Tiny VPN)
• Identity Aware Proxy (Next Gen Web Access Management)
• All of the Above

View Slide

Jericho: Zero Trust Fundamentals
76
JFC
#4
Devices and applications must communicate using open, secure
protocols.
JFC
#5
All devices must be capable of maintaining their security policy
on an un-trusted network. Designed for Internet
JFC
#6
All people, processes, and technology must have declared and
transparent levels of trust for any transaction to take place.
Multiple trust attributes (user, device, location, app etc)
JFC
#11
By default, Data must be appropriately secured when stored, in
transit, and in use.
Source: Jericho Forum Commandments v1.2 May 2007: https://collaboration.opengroup.org/jericho/commandments_v1.2.pdf

View Slide


View Slide

Zero Trust: Micro Segmentation
78
Source: Cisco: What is Micro Segmentation?
How does it work?
• Secures App by allowing specific Application Traffic and Deny All other Traffic
• Micro Segmentation is the foundation of Zero Trust Security Model
Challenges in Implementing Micro Segmentation
• Implement Granular Firewall Policy using Host workload Firewall
• Policy Life Cycle Management
• Begin at Macro Level and refine using Policy Automation
Why can’t Classic Firewalls do the job?
• Granular East-West Policy Controls provides Workload Perimeter
• Implemented at Workload Level
• Scalable across workloads
• Enhances the visibility and control from workload perspective

View Slide

Zero Trust: Micro Segmentation: Benefits
79
Source: Cisco: What is Micro Segmentation?
Reduce Attack Surface
Uses an allow-list model to significantly reduce this attack surface across different
workload types and environments.
Protect Critical Applications
Gain better threat visibility and enforcement for critical workloads and applications
across different platforms and environments, limiting lateral movement of a
security incident from one compromised VM, service, or container to another.
Achieve Regulatory Compliance
Granular visibility and control over sensitive workloads demonstrate proper
security and data separation to simplify audits and document compliance.

View Slide

NIST 800-207: Zero Trust Architecture
80
Source: NIST SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final
A User, An Application, or a Device – Operating on (or with) a Computer System which has access to an
Enterprise Resource
Subject
Is an Application, Document, Data, Database, Workload that’s under the Enterprise Control protected
by the Zero Trust System
Resource
Policy Enforcement Point
Policy Engine Policy Administrator
Policy Decision Point
Control
Plane
Data Plane Resource
Subject
User
App Device
UnTrusted Trusted
CDM
System
GRC
System
Threat
Intelligence
Activity
Logs
Data
Access
Policy
PKI
IAM
SIEM
1 2
3

View Slide

NIST 800-207: Zero Trust Architecture
81
PE – Policy
Engine
PA – Policy
Administrator
PEP – Policy
Enforcement
Point
Policy Decision Point PE is responsible to grant access to a resource for a given subject. The PE uses
enterprise policy as well as input from external sources (e.g., CDM systems,
threat intelligence, etc) as input to a trust algorithm to grant, deny, or revoke
access to the resource.
Source: NIST 800-207 https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture
PA is responsible for establishing and/or shutting down the communication. It
would generate any session-specific auth and auth token, or credential used by
a client to access an enterprise resource. PA configures the PEP to allow the
session to start. If the session is denied the PA signals to the PEP to shut down
the connection.
PEP is responsible for enabling, monitoring, and eventually terminating
connections between a subject and an enterprise resource. The PEP
communicates with the PA to forward requests and/or receive policy updates
from the PA.

View Slide

Software Defined Firewall: Network / Micro Segmentation
82
Network Segmentation using Software Defined Firewall Micro Segmentation using Software Defined Firewall
Source: https://www.vmware.com/topics/glossary/content/network-segmentation.html

View Slide

Traditional VPN Vs. Zero Trust
83
Enterprise
VPN
User System
VPN
Client
User
App
VPN
Server IAM
WAN
WAN
Split
Tunnel
Optional
Resource = Data, Documents, Apps, Services, Files etc.
Relies on Shared secret
and/or Shared root of Trust
If Split tunneling is enabled
only traffic to Enterprise
will be tunneled.
Zero Trust
User System
Agent
PEP
User
App
PEP
Encrypted Tunnel
Normal Traffic
LAN
IAM
PDP
PEP PEP
• Dynamically adjust the Context
• Multiple Entry Points
• Support Remote and On Premise
Resource
Resource Resource
Resource

View Slide

Zero Trust – Security: Resource Based
84
Device
Agent
PEP
ZT Aware
Network IDS/IPS
Control Plane
Data Plane
User
App
PEP
Gateway
Source: Page 183: Zero Trust Security: An Enterprise Guide by Jason Garbis, Jerry W Chapman
Resource Based
Deployment
Model
Zero Trust Deployment Models
Encrypted Tunnel
Data
Implicit Trust Zone
Zero Trust will bring changes to
network segmentation and
network traffic encryption
patterns.
Resource
Host IDS/IPS
Host IDS/IPS
ZT Aware
IDS/IPS

View Slide

Zero Trust – Security: Enclave Based
85
Device
Agent
PEP
ZT Aware
Network IDS/IPS
Control Plane
Data Plane
User
App
PEP
Gateway
Enclave Based
Deployment
Model
Encrypted Tunnel
Data
Implicit Trust Zone
Zero Trust will bring changes to
network segmentation and
network traffic encryption
patterns.
Resource Enclave
Host IDS/IPS
ZT Aware
IDS/IPS
Host IDS/IPS
Host IDS/IPS
NIDPS

View Slide

Zero Trust – Security: Cloud Routed
86
Device
PEP
Control
Plane
Data
Plane
User
App
Cloud Routed
Deployment
Model
PEP
Subject
ZT Aware
Network IDS/IPS
Agent
PEP
Host IDS/IPS
PEP
Gateway
Resource Enclave
Host IDS/IPS
Host IDS/IPS
NIDPS
Encrypted Tunnel
Data
Implicit Trust Zone

View Slide

Zero Trust – Security: Micro Segmentation
87
Micro Segmentation
Deployment
Model
PEP
Subject Resource
Host IDS/IPS
PEP
Subject Resource
Host IDS/IPS
ZT Aware
Network IDS/IPS

View Slide

Secure Web Gateway
88
Content Filtering Filter Content by specific URL or category to ensure internet access is based
on corporate policies.
Scan Docs Scan all the uploaded and downloaded files for malware and other threats.
File Types Block Files based on File Types Example .exe files.
App Controls
User access to Web Apps are controlled. For example, Uploading fille to Drop
Box, Google Drive etc. Attaching file to Gmail and Posting to Social Media
sites.
Metrics Detailed Reporting on User, Device, URLs accessed, network Identity and
Allow or Block Actions.

View Slide

Forrester: Zero Trust eXtended (ZTX)
89
Forrester Zero Trust extended Ecosystem: Aug 11, 2020
Zero Trust
Strategy
Zero Trust
Capability
Zero Trust
Technology
Zero Trust
Feature
Goal is to evolve towards a
Zero Trust Architecture or
Encrypt all Sensitive Data
For Ex. Data Security
Security teams need the ability
to inventory, classify, obfuscate,
archive, or delete data
according to policy
Ask
“What capabilities does this
technology support and where
does it specifically plug into my
team’s Zero Trust strategy?”

View Slide

Cloud Access Security Broker (CASB)
90
o CASB is the bridge between Cloud
Service Consumers and Cloud
Service Providers to combine and
interject enterprise security Policies
as the cloud-based resources are
consumed.
o They combine multiple types of
Security Policy Enforcement
Systems like Authentication, Single
Sign-On, Authorization, Credential
Mapping, Device Profiling,
Encryption, Tokenization, Malware
detection / prevention etc.
Visibility Compliance
Threat
Prevention
Data
Security
Source: Garnet CASB Definition

View Slide

Gartner: CARTA: 7 Core Areas
91
Continuous Adaptive Risk and Trust Assessment approach
Source: Gartner 2018
Replace one-time security gates with Context Aware, Adaptive & Programmable
Security Platforms
1
Continuously Discover, Monitor, Assess and Prioritize Risk – Proactively and Reactively
2
Perform Risk and Trust Assessment Early in Digital Business Initiatives
3
Instrument Infrastructure for Comprehensive, full stack Risk Visibility, Including
Sensitive Data Handling
4
Use Analytics, AI, Automation and Orchestration to speed the time to detect and
respond to scale
5
Architect Security as an Integrated, Adaptable Programmable System, and not Silos
6
Put Continuous Data Driven Risk Decision making and Risk Ownership into BU’s and
product owners
7

View Slide

Software Defined Perimeter – Context
92
o Classic Network Design creates fixed Perimeter to divide the External
Network with Internal Network
o Using Routers, Firewalls, and other access control devices.
o The concept of Classic Network is based on visibility and accessibility.
1. Today’s network is fluid with Hybrid clouds, IaaS, PaaS, SaaS, IoT, etc.,
all with multiple entry points.
2. This is further complicated by Contractors, Remote/Mobile Users,
BYOD etc.
ü These conditions gives rise to Software Defined Perimeter instead of a
traditional Fixed Perimeter
Cloud Security Alliance: May 27, 2020: SDP and Zero Trust

View Slide

Software Defined Perimeter
93
• SDP abstracts and hides internet connected infrastructure (Routers,
Servers etc.) irrespective of infra is On-Premise or Cloud.
• SDP Secures the user, application and the connectivity.
• Instead of traditional hardware-based perimeter setup, SDP is
completely software driven.
• VPN Connects the users to the Network using a simple
authentication
• While SDP allows the users to connect to the required resource using
real-time contextual risk assessment to determine user access.
According to Gartner more than 60% of Enterprises moved away from VPN by 2021

View Slide

Software Defined Perimeter – Principles
94
1. Separation of Control Plane and Data Plane. User, Devices etc
access is controlled using Control Plane. SDP Controller handles the
control plane.
2. Separation of logical and physical Components. The Connection
between hosts are virtualized using overlay tunnels.
3. Authenticating the Hosts. Only authorized systems/services allowed
to communicate.
4. Validating the Hosts against a set of policies. Checking for absence
of Malwares, allowed applications, business policies such as time of
the day, checking external Threat Intelligence Database.
Source: IEEE Software-Defined Perimeters: An Architectural View of SDP
SDP is not a replacement for existing solutions, it augments the existing solutions such as SDN.

View Slide

Software Defined Perimeter: Architecture
95
Policy
Enforcement Point
SDP Gateway
SDP Controller
Control Plane
Data Plane
Resource
Subject
User
App
Device
SDP
Client
Source: https://cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/
IH: Initiating Host
Control Messages
Data
SDP requires
2 Security
modules
1. mTLS
2. SPA
AH
AH: Accepting Host
The model depicted below is Similar to Enclave Resource model from NIST 800-207 Architecture. NIST team
defined that based on Cloud Security Alliance SDP Architecture.

View Slide

SDP – Secure Communications
96
mTLS – Mutual
Transport Layer Security
SPA – Single Packet
Authorization
• Both Client and Server need to
validate the certificate
• Expect Mutual Root
Certificates for Client & Server
• Avoids Man in the Middle
Attack
HOTP: An HMAC-Based One-Time Password Algorithm
Authenticate before Connect
• Default Policy in SDP Gateway is
Drop All Packets
• Based on RFC 4226: HOTP
• SPA happens before TLS Connection
• For Valid Connections Firewall rule
is created for mTLS connection

View Slide

SASE: Secure Access Service Edge
97
Created by Gartner: Six Core Technologies of SASE
Network
Security
SASE
SD-WAN
ZTNA
Zero Trust Network Access
SWG
Secure Web Gateway
CASB
Cloud Access Security Broker
FWaaS
Firewall as a Service
DNS
Security

View Slide

SASE: Overview
98
o Users
o Devices
o Locations
o Public Cloud
o Data Center
o Edge
Identity Context
Consistent Network & Security Policy
SASE Cloud Infrastructure
WAN Edge
Infrastructure
/ Services
Security
Services
Edge
Threat
Awareness
Sensitive Data
Awareness
Entities Anywhere Resources Everywhere
Zero Trust Access
Consistent User Experience
Source: Gartner 2021 Strategic
Roadmap for SASE Convergence,
March 25, 2021By Neil
MacDonald, Nat Smith, Lawrence
Orans, Joe Skorupa

View Slide

Key Takeaways
99
• NIST Secure Software Development Framework
• SANS Cloud Security Architecture
• Security Quality Assurance / SQUARE Framework
• Secure Design Patterns
• Threat Modeling
• Enterprise Security (Zero Trust, SDN, SDP)

View Slide

2
Secure SDLC
o Security Policies / Kubernetes Policies
o Service Mesh
o Server Hardening
100

View Slide

Kubernetes Policies
o Network Policies
o Security Policies
101

View Slide

OSI Layers
102

View Slide

K8s Network Policies – L3 / L4
103
Source: https://github.com/meta-magic/kubernetes_workshop
Allow All Inbound
Allow All Outbound
endPort for Range of Ports

View Slide

K8s Network Policies L3/L4
104
Kubernetes blocks the
Product UI to access
Database or Product
Review directly.
You can create Network
policies across name
spaces, services etc., for
both incoming (Ingress)
and outgoing (Egress)
traffic.
Product UI Pod
Product UI Pod
Product UI Pod
Product Pod
Product Pod
Product Pod
Review Pod
Review Pod
Review Pod
MySQL
Pod
Mongo
Pod
Order UI Pod
Order UI Pod
Order UI Pod
Order Pod
Order Pod
Order Pod
Oracle
Pod
Blocks Access
Blocks Access

View Slide

Network Security Policy for Microservices
105
Product Review
Microservice
Product
Microservice
172.27.1.2
L3 / L4
L7 – API
GET /live
GET /ready
GET /reviews/{id}
POST /reviews
PUT /reviews/{id}
DELETE /reviews/{id}
GET /reviews/192351
Product review can be accessed ONLY by
Product. IP Tables enforces this rule.
Exposed
Exposed
Exposed
Exposed
Exposed
All other method calls are also
exposed to Product Microservice.
iptables –s 172.27.1.2
-p tcp –dport 80
-j accept

View Slide

Network Security Policy for Microservices
106
Product Review
Microservice
Product
Microservice
L3 / L4
L7 – API
GET /live
GET /ready
GET /reviews/{id}
POST /reviews
PUT /reviews/{id}
GET /reviews/192351
Rules are implemented by BPF (Berkeley
Packet Filter) at Linux Kernel level.
From Product Microservice
only GET /reviews/{id}
allowed.
BPF / XDP performance is much
superior to IPVS.
Except GET /reviews All other
calls are blocked for Product
Microservice

View Slide

Cilium Network Policy
107
1. Cilium Network Policy works in sync with
Istio in the Kubernetes world.
2. In Docker world Cilium works as a network
driver and you can apply the policy using
ciliumctl.
In the previous example with Kubernetes
Network policy you will be allowing access to
Product Review from Product Microservice.
However, that results in all the API calls of
Product Review accessible by the Product
Microservice.
Now with the New Policy only GET /reviews/{id}
is allowed.
These Network policy gets executed at Linux
Kernel using BPF.
Product
Microservice can
access ONLY
GET /reviews from
Product Review
Microservice
User Microservice
can access
GET /reviews &
POST /reviews from
Product Review
Microservice

View Slide

BPF / XDP (eXpress Data Path)
108
Network Driver Software Stack
Network Card
BPF
Regular BPF (Berkeley Packet Filter) mode
Network Card
BPF
XDP allows BPF program to run inside the network driver with access to DMA buffer.
Berkeley Packet Filters (BPF) provide a powerful tool for intrusion detection analysis.
Use BPF filtering to quickly reduce large packet captures to a reduced set of results
by filtering based on a specific type of traffic.
Source: https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.3.2/com.ibm.qradar.doc/c_forensics_bpf.html

View Slide

XDP (eXpress Data Path)
109
BPF Program can
drop millions packet
per second when
there is DDoS attack.
Network Card
BPF
Drop
Stack
Network Card
BPF
Drop
Stack
LB & Tx
BPF can perform
Load Balancing and
transmit out the
data to wire again.
Source: http://www.brendangregg.com/ebpf.html

View Slide

Kubernetes Container Network Interface
110
Container Runtime
Container Network Interface
Weave Calico Romana Cilium Flannel
Layer 3
BGP
BGP Route Reflector
Network Policies
IP Tables
Stores data in Etcd
Project Calico
Layer 3
VXLAN (No Encryption)
IPSec
Overlay Network
Host-GW (L2)
Stores data in Etcd
https://coreos.com/
Layer 3
IPSec
Network Policies
Multi Cloud NW
Stores data in Etcd
https://www.weave.works/
Layer 3
L3 + BGP & L2 +VXLAN
IPSec
Network Policies
IP Tables
Stores data in Etcd
https://romana.io/
Layer 3 / 7
BPF / XDP
L7 Filtering using BPF
Network Policies
L2 VXLAN
API Aware (HTTP, gRPC,
Kafka, Cassandra… )
Multi Cluster Support
https://cilium.io/
BPF (Berkeley Packet Filter) – Runs inside the Linux Kernel
On-Premise Ingress Load Balancer
Mostly Mostly Yes Yes Yes

View Slide

Service Mesh
o Authorization Policies
o Peer Authentication
o Request Authentication (JWT Authorization)
111

View Slide

Service Mesh: Istio Security
112
Source: https://istio.io/docs/concepts/security/
It provide strong identity, powerful policy, transparent TLS encryption, and authentication,
authorization and audit (AAA) tools to protect your services and data. The goals of Istio
security are
• Security by default: no changes
needed for application code
and infrastructure
• Defense in Depth: integrate
with existing security systems to
provide multiple layers of
Defense
• Zero-trust network: build
security solutions on untrusted
networks

View Slide

Service Mesh: Istio Security Architecture
113
Source: https://istio.io/latest/docs/concepts/security/

View Slide

Service Mesh: Micro Segmentation
114
Source: Istio: Micro-Segmentation with Istio Authorization https://istio.io/latest/blog/2018/istio-authorization/
• Authorization at different levels of granularity, including
namespace level, service level, and method level.
• Service-to-service and end-user-to-service authorization.
• High performance, as it is enforced natively on Envoy.
• Role-based semantics, which makes it easy to use.
• High flexibility as it allows users to define conditions
using combinations of attributes.

View Slide

Istio Security Policy for Microservices
115
Product Review
Microservice
Product
Microservice
L3 / L4
L7 – API
GET /live
GET /ready
GET /reviews/{id}
POST /reviews
PUT /reviews/{id}
GET /reviews/192351
Rules are implemented by BPF (Berkeley
Packet Filter) at Linux Kernel level.
From Product Microservice
only GET /reviews/{id}
allowed.
BPF / XDP performance is much
superior to IPVS.
Except GET /reviews All other
calls are blocked for Product
Microservice

View Slide

Deployments
116

View Slide

Service Accounts / Authorization Policy
117

View Slide

Peer Authentication for Microservice
118

View Slide

Peer Authentication for Mesh / Namespace
119
Mode
• STRICT
• PERMISSIVE
• DISABLED

View Slide

Request Authentication
120
• kty: Key type, can be RSA or ECDSA.
• e: The exponent for a standard to a public key.
• n: The modulus for a standard to a public key.
• alg: Specifies the algorithm intended to be used
with the key.
• kid: The unique identifier for the key.

View Slide

Service Mesh: Micro Segmentation
121
Source: Istio: Micro-Segmentation with Istio Authorization https://istio.io/latest/blog/2018/istio-authorization/
• Authorization at different levels of granularity, including namespace
level, service level, and method level.
• Service-to-service and end-user-to-service authorization.
• High performance, as it is enforced natively on Envoy.
• Role-based semantics, which makes it easy to use.
• High flexibility as it allows users to define conditions
using combinations of attributes.

View Slide

Istio –
Traffic Management
• Gateway
• Virtual Service
• Destination Rule
• Service Entry
122

View Slide

Istio Sidecar Automatic Injection
123

View Slide

Kubernetes & Istio - Kinds
124
# Kubernetes # Istio Kinds Description
1 Ingress
1 Gateway Exposes Ports to outside world
2 Virtual Service Traffic Routing based on URL path
3 Destination Rule Traffic Routing based on Business Rules
2 Service
4 Service Entry External Service Definition
3 Service Account
4 Network Policy
5 Peer Authentication Enables mTLS across Mesh, Namespace etc.
6 Request Authentication Authenticates using JWTs
7 Authorization Policy More granular Network/Security Policies

View Slide

Istio – Traffic Management
125
Virtual Service
Gateway
Destination Rule
Routing Rules Policies
• Match
• URI Patterns
• URI ReWrites
• Headers
• Routes
• Fault
• Fault
• Route
• Weightages
• Traffic Policies
• Load Balancer
Configures a load balancer for HTTP/TCP
traffic, most commonly operating at the
edge of the mesh to enable ingress traffic
for an application.
Defines the rules
that control how
requests for a
service are routed
within an Istio
service mesh.
Configures the set of policies
to be applied to a request
after Virtual Service routing
has occurred.

View Slide

Gateway
126
Gateway describes a load balancer
operating at the edge of the
mesh receiving incoming or
outgoing HTTP/TCP connections.
The Gateway specification above
describes the L4-L6 properties of a load
balancer.

View Slide

Gateway with
multiple sub
domains
127
In this Gateway configuration sets up
a proxy to act as a load balancer
exposing
• port 80 and
• 443 (https),
for ingress.
Multiple Sub-domains are mapped to
the single Load Balancer IP Address.
TLS Termination is done using
product-credential (secret)

View Slide

Virtual Service
128
Routing Rules are defined per service (best practice)

View Slide

Destination Rule
129
Configures the set of
policies to be applied to
a request after Virtual
Service routing has
occurred.

View Slide

Service Entry
130
MESH_EXTERNAL Signifies that the service is external to the
mesh. Typically used to indicate external
services consumed through APIs.
MESH_INTERNAL Signifies that the service is part of the mesh.
A service entry describes the properties
of a service
• DNS name,
• VIPs (Virtual IPs)
• ports, protocols
• endpoints

View Slide

Shopping Portal – Docker / Kubernetes
131
/ui
/productms
/productreview
Load Balancer
Ingress
UI Pod
UI Pod
UI Pod
UI Service
Product Pod
Product Pod
Product Pod
Product Service
Review Pod
Review Pod
Review Pod
Review Service
Deployment / Replica / Pod
N1
N2
N2
Nodes
N4
N3
MySQL
Pod
N4
N3
N1
Kubernetes Objects
Firewall
Service Call
Kube DNS
EndPoints
EndPoints
EndPoints
Internal
Load Balancers

View Slide

Shopping Portal - Istio
132
/ui
/productms
/productreview
Gateway
Virtual Service
UI Pod
UI Pod
UI Pod
UI Service
Product Pod
Product Pod
Product Pod
Product
Service
Review Pod
Review Pod
Review Pod
Review
Service
MySQL
Pod
N1
N2
N2
N4
N1
N3
N4
N3
Nodes
Istio Sidecar
Envoy
Destination
Rule
Destination
Rule
Destination
Rule
Load Balancer
Kubernetes Objects
Istio Objects
Firewall
istiod
Istio Control Plane
Service Call
Kube DNS
EndPoints
EndPoints
EndPoints
Internal
Load Balancers

View Slide

Shopping Portal
133
/ui
/productms
/productreview
Gateway
Virtual Service
UI Pod
UI Pod
UI Pod
UI Service
Product Pod
Product Pod
Product Pod
Product
Service
Review Pod
Review Pod
Review Pod
Review
Service
N1
N2
N2
MySQL
Pod
N4
N3
N1
N4
N3
Nodes
Istio Sidecar - Envoy
Destination
Rule
Destination
Rule
Destination
Rule
Load Balancer
Kubernetes Objects
Istio Objects
Firewall
UI Pod N5
v1
v2
Stable / v1
Canary
v2
User X = Canary
Others = Stable
A / B Testing using
Canary Deployment
Service Call
Kube DNS
EndPoints
EndPoints
EndPoints
Internal
Load Balancers
Istio Control Plane istiod

View Slide

Shopping Portal
134
/ui
/productms
/productreview
Gateway
Virtual Service
UI Pod
UI Pod
UI Pod
UI Service
Product Pod
Product Pod
Product Pod
Product
Service
Review Pod
Review Pod
Review Pod
Review
Service
N1
N2
N2
MySQL
Pod
N4
N3
N1
N4
N3
Nodes
Destination
Rule
Destination
Rule
Destination
Rule
Load Balancer
Kubernetes Objects
Istio Objects
Firewall
UI Pod N5
v1
v2
Stable / v1
Canary
v2
10% = Canary
90% = Stable
Traffic Shifting
Canary Deployment
Service Call
Kube DNS
EndPoints
EndPoints
EndPoints
Internal
Load Balancers

View Slide

Shopping Portal
135
/ui
/productms
/productreview
Gateway
Virtual Service
UI Pod
UI Pod
UI Pod
UI Service
Product Pod
Product Pod
Product Pod
Product
Service
Review Pod
Review Pod
Review Pod
Review
Service
N1
N2
N2
MySQL
Pod
N4
N3
N1
N4
N3
Nodes
Destination
Rule
Destination
Rule
Destination
Rule
Load Balancer
Kubernetes Objects
Istio Objects
Firewall
UI Pod N5
v1
v2
Stable / v1
Canary
v2
100% = v2
Blue Green
Deployment
Service Call
Kube DNS
EndPoints
EndPoints
EndPoints
Internal
Load Balancers

View Slide

Shopping Portal
136
/ui
/productms
/productreview
Gateway
Virtual Service
UI Pod
UI Pod
UI Pod
UI Service
Product Pod
Product Pod
Product Pod
Product
Service
Review Pod
Review Pod
Review Pod
Review
Service
N1
N2
N2
MySQL
Pod
N4
N3
N1
N4
N3
Nodes
Destination
Rule
Destination
Rule
Destination
Rule
Load Balancer
Kubernetes Objects
Istio Objects
Firewall
UI Pod N5
v1
v2
Stable / v1
Canary
v2
100% = Stable
Mirror = Canary
Mirror Data
Service Call
Kube DNS
EndPoints
EndPoints
EndPoints
Internal
Load Balancers

View Slide

Circuit Breaker Pattern
137
/ui
/productms
If Product Review is not
available Product service will
return the product details
with a message review not
available.
Reverse Proxy Server
Ingress
Deployment / Replica / Pod Nodes
Kubernetes Objects
Firewall
UI Pod
UI Pod
UI Pod
UI Service
N1
N2
N2
EndPoints
Product Pod
Product Pod
Product Pod
Product Service
N4
N3
MySQL
Pod
EndPoints
Internal
Load Balancers
Users
Routing based on Layer 3,4 and 7
Review Pod
Review Pod
Review Pod
Review Service
N4
N3
N1
Service Call
Kube DNS
EndPoints

View Slide

Destination Rule
138
Configures the set of
policies to be applied to
a request after Virtual
Service routing has
occurred.

View Slide

Shopping Portal:
139
/ui
/productms
/productreview
Gateway
Virtual Service
UI Pod
UI Pod
UI Pod
UI Service
Review Pod
Review Pod
Review Pod
Review
Service
N1
N2
N2
MySQL
Pod
N4
N3
N1
N4
N3
Nodes
Destination
Rule
Destination
Rule
Destination
Rule
Load Balancer
Kubernetes Objects
Istio Objects
Firewall
v1
Fault Injection
Delay = 7 Sec
Abort = 10%
Fault Injection
Product Pod
Product Pod
Product Pod
Product
Service
Service Call
Kube DNS
EndPoints
EndPoints
EndPoints
Internal
Load Balancers

View Slide

Fault Injection
140
Introducing an artificial
Delay of 7 second
&
Abort 10% of traffic.
It’s a best practice to
have all the rules for the
(product) microservice in
a single Virtual Service.

View Slide

Hardening the Server
o Linux / Apache / Tomcat Server
o PostgreSQL / MySQL
o MongoDB / Redis
141

View Slide

Linux Hardening
142
1. Minimize Software to Reduce Vulnerability: Install only the
necessary necessary packages, services, and libraries.
2. Keep System Updated: Regularly apply patches and updates to your
system to mitigate known vulnerabilities.
3. Limit User and File Permissions: Only give users and processes the
permissions they absolutely need (principle of least privilege).
4. Enable a Firewall: Utilize a firewall like iptables or ufw to restrict
unwanted incoming and outgoing network traffic.
5. Use Security Enhancements: Enable security modules like SELinux or
AppArmor which enforce access control policies.

View Slide

Linux Hardening – iptables
143
• -F: The flush option. This is used to delete all the rules in the selected chain (or all chains if none is given). It
effectively resets the firewall rules to their default state.
• -P: The policy option. This is used to set the default policy (target) for a chain. It can be set to ACCEPT, DROP,
QUEUE, or RETURN.
• -A: The append option. This is used to add a rule to the end of a selected chain.
• -D: The delete option. This is used to delete one or more rules from the selected chain.
• -I: The insert option. This is used to insert a rule at a specific position in a chain.
• -N: The new-chain option. This is used to create a new user-defined chain.
• -X: The delete-chain option. This is used to delete a user-defined chain.
• -L: The list option. This is used to list all the rules in a chain. –L –v - -line-numbers
• -S: The list-rules option. This is used to print all rules in the selected chain.
• -Z: The zero option. This is used to zero the packet and byte counters in all chains.
• -j: The jump option. This specifies the target of the rule; i.e., what to do if the packet matches it.
• -p: The protocol option. This matches the protocol, such as tcp, udp, icmp, etc.
• --dport: The destination port option. This is used in conjunction with -p to match the destination port on
which the packet is sent.

View Slide

iptables Examples
144
sudo iptables -F
$
Flush/remove all existing iptables rules.
Be careful as this will remove all your existing rules.
sudo iptables -P INPUT DROP
$
Set the default policy for the input chain to drop.
This will drop all packets that don't match any rule:
sudo iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
$
Allow incoming connections on port 8080:
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
$
Allow SSH connections (usually on port 22)
sudo sh -c 'iptables-save > /etc/iptables/rules.v4'
$
Save the iptables rules so they survive a system reboot.
sudo systemctl enable iptables
$
Ensure that the rules are applied at startup

View Slide

ufw (Uncomplicated Firewall) Examples
145
sudo ufw default deny incoming
$
Deny all incoming connections by default
sudo ufw allow 8080
$
Allow incoming connections on port 8080
sudo ufw allow ssh
$
Allow SSH connections (usually on port 22)
sudo ufw status verbose
$
You can check your current ufw rules with
sudo ufw enable
$
Enable ufw

View Slide

Tomcat Server Hardening
146
1. Remove Default/Example Applications: These applications may not
be secure and are often targets for attackers.
2. Restrict Access to Certain Files and Directories: Ensure
unauthorized users cannot access sensitive files like configuration
files and directories.
3. Use a Firewall: Limit access to the Tomcat server to only necessary
networks and IP addresses.
4. Keep Tomcat Updated: Regularly apply patches and updates
provided by Apache.
5. Use SSL/TLS: Enable SSL/TLS for encryption of data in transit.

View Slide

Tomcat Server Hardening
147

Secured Area
/secured/*
GET
POST

role1

BASIC
default

role1

In this example, any HTTP GET or
POST requests to URLs that match
the pattern /secured/* will be
restricted to users who have been
assigned the role1 role.
The element specifies
that the server should use HTTP
Basic Authentication to prompt the
user for their username and
password.
This requires you to have a Realm
configured to authenticate users and
determine their roles.
SpringBoot takes care of this using
Spring Security.

View Slide

Apache Web Server Hardening
148
1. Minimize Modules: Disable any modules that are not necessary
for your operations.
2. Enable SSL/TLS: Just like with Tomcat, enable SSL/TLS to encrypt
data in transit.
3. Restrict Directory and File Access: Set appropriate file permissions
and use the Directory directive to control access.
4. Hide Server Version Information: Modify ServerTokens and
ServerSignature directives to avoid revealing Apache version info.
5. Use a Web Application Firewall (WAF): A WAF like ModSecurity
can help protect your web server from common attacks like SQL
injection or cross-site scripting (XSS).

View Slide

Apache Web Server
149
sudo vi /etc/httpd/conf/httpd.conf
$
The configuration file is typically located at
/etc/httpd/conf/httpd.conf or /etc/apache2/apache2.conf
ServerTokens Prod
$
The Prod parameter causes Apache to return only Apache as
product in the Server response header on the HTTP response,
not revealing any version information.
ServerSignature Off
$
The Off parameter causes Apache not to reveal the server
version in ServerSignature if a page is not found or if an error
occurs.
sudo a2dismod autoindex
$
On a Debian or Ubuntu system, Apache provides the
a2dismod utility to disable modules (autoindex).
# LoadModule autoindex_module
modules/mod_autoindex.so
$
On a Red Hat or CentOS system, modules are typically
loaded through directives in configuration files.

View Slide

Docker Container Hardening
150
1. Use Trusted Images: Only use Docker images from trusted sources and
keep them updated.
2. Don't Run Containers as Root: Run your containers as a non-root user
whenever possible.
3. Use Docker Bench for Security: This is a script that checks for common
best-practices around deploying Docker containers in production.
4. Use Namespaces and CGroups: Docker uses these Linux features to
isolate containers and limit their resources, adding an extra layer of
security.
5. Limit Inter-container Communications: Use network segmentation to
limit which containers can communicate with each other.

View Slide

Docker Bench for Security
151
docker pull docker/docker-bench-security
$
You can run Docker Bench for Security as a Docker container itself. This has the advantage of not requiring any
dependencies on the host other than Docker
docker run -it --net host --pid host --userns host --cap-add audit_control \
-e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
-v /var/lib:/var/lib \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/lib/systemd:/usr/lib/systemd \
-v /etc:/etc --label docker_bench_security \
docker/docker-bench-security
$
After the Docker image is pulled, you can run Docker Bench for Security with this command:
This command runs Docker Bench for Security with several options to give it access to various parts of the host system. This
is necessary because Docker Bench for Security checks many aspects of the Docker installation that require access to certain
directories and files on the host.
After running Docker Bench for Security, it will output a report to the console. This report contains information about each
test it performed, whether it passed or failed, and details about what the test checks for.

View Slide

Linux AppArmour for Container Security
152
#include
profile docker-myprofile flags=(attach_disconnected,mediate_deleted) {
#include
deny /etc/** w,
}
1. Write your AppArmor profile. This is a file that specifies what the container is and isn't allowed to do. Here
is a very basic example that denies write access to the /etc/ directory
sudo apparmor_parser -r -W docker-myprofile
$
2. Load the profile into the kernel using the apparmor_parser utility:
docker run --security-opt apparmor=docker-myprofile -it ubuntu bash
$
3. When running a new Docker container, apply your profile using the --security-opt option:

View Slide

Linux Sample AppArmour Profile
153
#include
profile docker-nginx
flags=(attach_disconnected,medi
ate_deleted) {
#include
network inet stream,
network inet6 stream,
deny network raw,
deny /etc/ssh/* w,
deny /etc/passwd w,
deny /etc/shadow w,
deny /etc/group w,
owner /var/log/nginx/* rw,
owner /var/lib/nginx/* rw,
/usr/sbin/nginx ix,
deny /var/lib/docker/** w,
deny /proc/*/mount rw,
deny /proc/*/mnt rw,
deny /proc/*/mounts r,
capability net_bind_service,
file,
pivot_root,
umount,
deny /bin/** ix,
deny /sbin/** ix,
deny /usr/bin/** ix,
deny /usr/sbin/** ix,
audit deny @{PROC}/{*,**^[0-
9*],sys/kernel/shm*} rwklx,
audit deny @{PROC}/{sysrq-
trigger,mem,kcore,kmem} rwklx,
deny mount,
deny /etc/grub.d/** r,
deny /etc/lilo.conf r,
deny /boot/grub/menu.lst r,
}
This profile includes the following rules:
• Allows the Nginx server to create network
connections.
• Denies raw socket access, which can be used for
low-level network attacks.
• Denies write access to sensitive system files such
as /etc/passwd.
• Allows the Nginx server to read and write its own
log files and other necessary files.
• Denies write access to Docker's own files.
• Prevents the container from viewing or altering
mount points.
• Allows the container to bind to network ports <
1024.
• Denies execution of binaries except for
/usr/sbin/nginx.
• Denies access to sensitive locations in the /proc
filesystem.
• Denies ability to mount filesystems.
• Denies read access to boot loader configuration
files

View Slide

Linux AppArmour in Kubernetes
154
apiVersion: v1
kind: Pod
metadata:
name: mypod
annotations:
container.apparmor.security.beta.kubernetes.io/mycontainer: localhost/myprofile
spec:
containers:
- name: mycontainer
image: myimage
The must be one of:
• runtime/default: The default profile for the container runtime will be used.
• localhost/: A pre-loaded profile on the node will be used.
So, when you see localhost/myprofile, it's saying "use the AppArmor profile named myprofile that has been
pre-loaded on this node." The profiles are typically loaded on the node's operating system from the
/etc/apparmor.d/ directory.

View Slide

PostgreSQL Database Hardening
155
1. Network Level Security:
1. PostgreSQL listens on all interfaces by default, but in a production setting, it should be
configured to listen only on the interfaces where it's actually needed. This is defined in the
postgresql.conf file with the listen_addresses directive.
2. Implement firewall rules to limit incoming connections only from trusted IP addresses. You
can do this with firewall management tools such as iptables or ufw on Linux.
2. Database Access:
1. Use strong passwords for all your PostgreSQL accounts.
2. Don't use the PostgreSQL superuser for application connections, use a database-specific user
with limited rights.
3. Limit connection rights using the pg_hba.conf file. Here, you can control which hosts are
allowed to connect, how clients are authenticated, which PostgreSQL user names they can
use, which databases they can access.

View Slide

156
3. Encryption:
• Use SSL to encrypt client/server communications. This can be done by setting the ssl
directive to on in postgresql.conf and setting up SSL certificates.
4. Database Roles and Permissions:
• Grant minimum necessary privileges to database roles. PostgreSQL provides role-
based access control with a rich set of permissions and privilege types.
5. Database Auditing:
• PostgreSQL includes detailed logs which can provide valuable information about
access and usage, enable it by modifying the settings in postgresql.conf.
6. Regular Updates:
• Regularly apply patches and updates to PostgreSQL. Newer versions often contain
security fixes and other improvements.

View Slide

157
7. Data Backup:
• Implement regular database backups and ensure that backups are securely
stored.
8. Database Extensions and Add-Ons:
• Only install trusted extensions and add-ons. They run with the same
permissions as PostgreSQL and can become a security risk if they are not
from a trusted source.
9. Database Hardening:
• Follow PostgreSQL hardening guidelines such as those found in the CIS
PostgreSQL Benchmark.

View Slide

158
listen_addresses = 'localhost'
postgresql.conf
Restrict listening addresses: The listen_addresses parameter determines the IP address(es) that PostgreSQL will bind to. In
most cases, it's a good idea to bind to localhost (127.0.0.1) or specific trusted IPs rather than binding to all available IPs
(0.0.0.0). This can be done by setting listen_addresses to localhost or the specific IP.
# TYPE DATABASE USER ADDRESS METHOD
host all all 192.168.1.0/24 md5
pg_hba.conf
This tells PostgreSQL to accept connections from any IP address in the range 192.168.1.0 - 192.168.1.255 (192.168.1.0/24),
using md5 password authentication.
listen_addresses = ‘0.0.0.0'
listen_addresses = '192.168.1.1,192.168.1.2'
# TYPE DATABASE USER ADDRESS METHOD
host healthcaredb hcapp 192.168.1.0/24 scram-sha-256
JDBC Driver automatically negotiates with the DB Server for the Hashing Method and uses the appropriate ones.
Recommended

View Slide

159
1. Trust: The trust method allows connections without requiring a password. It's suitable only for local
connections on trusted networks.
2. Reject: The reject method unconditionally rejects attempts to connect.
3. MD5: The md5 method encrypts the password using MD5 before sending it over the network. It's more
secure than sending plaintext passwords, but not as secure as using certificate-based or GSSAPI/Kerberos
authentication.
4. Password (clear-text): The password method sends the password in clear text, and it's not recommended
for connections over the internet.
5. SCRAM-SHA-256: SCRAM-SHA-256 is a password-based authentication method that is more secure than
md5. It uses the SCRAM method with the SHA-256 hash function for password storage and verification.
6. GSSAPI and Kerberos: These are more advanced methods that use an external trusted third party for
authentication.
7. Ident: This method works by obtaining the client's operating system user name, with an optional map to
match it to the allowed database user names.
8. Peer: This method is similar to ident but is used for local connections and checks the client's operating
system user name against the allowed database user names.
9. LDAP, RADIUS, Cert, and PAM: These methods use external services for authentication.

View Slide

MongoDB Hardening
160
security:
authorization: "enabled"
Enable Access Control and Enforce Authentication (mongod.conf)
Enabling access control on a MongoDB deployment enforces authentication, requiring users to identify themselves. When
access control is enabled, MongoDB requires all clients to authenticate themselves in order to determine their access.
net:
ssl:
mode: requireSSL
PEMKeyFile: /etc/ssl/mongodb.pem
Encrypt Communitcation
Configure MongoDB to use SSL for all incoming and outgoing connections. Use the net.ssl setting in your MongoDB
configuration file.

View Slide

MongoDB Hardening
161
security:
enableEncryption: true
encryptionKeyFile: /data/key/mongodb-keyfile
Encrypt Data At Rest
MongoDB Enterprise includes native encryption at rest for additional on-disk encryption. Data at rest encryption encrypts
the on-disk storage for MongoDB data files.
net:
bindIp: localhost,192.168.1.101
Limit Network Exposure
Ensure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for
incoming connections. Bind to local and internal IP addresses

View Slide

MongoDB – mongod.conf
162
storage:
dbPath: /var/lib/mongodb
journal:
enabled: true
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
net:
bindIp: localhost,192.168.1.101
port: 27017
ssl:
mode: requireSSL
PEMKeyFile: /etc/ssl/mongodb.pem
security:
authorization: "enabled"
javascriptEnabled: false
enableEncryption: true
encryptionKeyFile: /data/key/mongodb-keyfile
The mongod.conf file is usually located under
/etc/mongod.conf in Unix/Linux systems, and
C:\Program
Files\MongoDB\Server\4.2\mongod.cfg in
Windows systems.
The paths may vary depending on your
MongoDB version and your operating system.
This is just an example. The actual contents of
your mongod.conf file will depend on your
specific MongoDB configuration and your
security requirements.

View Slide

MySQL Database Hardening
163
mysql_secure_installation
$
Change the Root Password
Run the mysql_secure_installation script, which enables you to change the root password and remove anonymous user
accounts.
[mysqld]
bind-address = 127.0.0.1
Limit MySQL network exposure
You can configure MySQL to listen only on localhost by modifying the mysql.cnf (or my.cnf, depending on your Linux distro)
file:
CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'password';
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP ON `database`.* TO 'newuser'@'localhost';
Create distinct users for different operations and applications
Instead of using a root account for all operations, it is better to create different users with the minimum required privileges.
Here's an example:

View Slide

MySQL Database Hardening
164
Use strong passwords
Always enforce the usage of strong passwords. MySQL 8.0 and above supports a validate_password plugin to enforce
password policies.
Remove or disable unused databases
By default, MySQL installs a test database. It is recommended to remove this database in a production set-up.
Keep MySQL up to date
Regularly update your MySQL server with the latest security patches and versions.
chown root:root /etc/mysql/my.cnf
$
Secure MySQL configuration
Protect your my.cnf file by setting the appropriate ownership and permissions:
chmod 644 /etc/mysql/my.cnf
$

View Slide

Redis Database Hardening
165
bind 127.0.0.1
Bind to a specific IP address
By default, Redis listens for connections from all the network interfaces available on the server. This might not be what you
want, especially if it's exposed on the internet. To bind Redis to a specific IP address, locate the bind configuration directive
and set it to the desired IP address.
For instance, if you want Redis to listen for connections only from the local machine, modify the redis.conf file:
requirepass your-strong-password
Enable Redis authentication
It is a good idea to enable authentication for your Redis server to ensure only authenticated users can interact with the
database. You can set the authentication password as follows in the redis.conf file:
rename-command CONFIG ""
rename-command FLUSHDB ""
rename-command FLUSHALL ""
Rename or disable certain commands
Certain Redis commands are considered dangerous when executed by unauthorized users. You can rename or completely
disable these commands: In this example, the CONFIG, FLUSHDB, and FLUSHALL commands have been disabled.

View Slide

Redis Database Hardening
166
protected-mode yes
Update default settings for protected mode
In recent versions of Redis, there is a feature called "protected mode" which prevents potentially harmful operations from
being executed by unauthorized users. Protected mode is enabled by default. You should ensure it stays enabled unless you
specifically want to disable it:
maxclients 1000
Limiting simultaneous connections
Limit the number of clients that can connect to Redis simultaneously to avoid resource exhaustion from client connections:
Run Redis as a non-root user
Running Redis as a non-root user minimizes the potential damage that could be caused if Redis were to be exploited. You
can change the user by editing the redis.service file in systemd.

View Slide

3
DevOps & SRE
o DevOps
o SRE
o Best Practices
o Case Studies
167

View Slide

Agile
Scrum (4-6 Weeks)
Developer Journey
Monolithic
Event Sourcing and CQRS
Waterfall
Optional
Design
Patterns
Continuous Integration (CI)
6/12 Months
Enterprise Service Bus
Relational Database [SQL] / NoSQL
Development QA / QC Ops
168
Microservices
Event Sourcing and CQRS
Scrum / Kanban (1-5 Days)
Mandatory
Design
Patterns
Infrastructure Design Patterns
CI
DevOps
Event Streaming / Replicated Logs
SQL NoSQL
CD
Container Orchestrator Service Mesh

View Slide

Application Modernization – 3 Transformations
169
Monolithic SOA Microservice
Physical
Server
Virtual
Machine
Cloud
Waterfall Agile DevOps
Source: IBM: Application Modernization > https://www.youtube.com/watch?v=RJ3UQSxwGFY
Architecture
Infrastructure
Delivery

View Slide

Application Modernization – 3 Transformations
170
Monolithic SOA Microservice
Physical
Server
Virtual
Machine
Cloud
Waterfall Agile DevOps
Source: IBM: Application Modernization > https://www.youtube.com/watch?v=RJ3UQSxwGFY
Architecture
Infrastructure
Delivery
Modernization
1
2
3

View Slide

171
Source:
Page 16
US DoD Enterprise
DevSecOps 2.0
Fundamentals

View Slide

172
Source:
Page 16
US DoD Enterprise
DevSecOps 2.0
Fundamentals

View Slide

DevOps
o ITIL
o Development and Operations – Silos
o Lean Thinking
o CALMS Framework
o SpecOps – SDLC
o 5 Principles of DevOps
173

View Slide

ITIL – Service Life Cycle
174
Source: https://www.flycastpartners.com/itil-service-lifecycle-guide/
• ITIL is a framework providing best practice guidelines
on all aspects of end to end service management.
• It covers complete spectrum of People, Processes,
Products and use of Partners (v3).
Service is a means of delivering value to customers
by achieving customer's desired results while
working within given constraints.
Incident is defined as any disruption in IT service.
Service Level Agreement. It is a commitment between a
service provider and a client.

View Slide

Development & Operations
175
Development Team
Agility
Operations Team
Stability
Developers
Keep throwing
releases over
the wall and
get pushed
back by the
operations
team.

View Slide

DevOps History
176
DevOps isn’t simply a process or a different approach to development
— it’s a culture change.
And a major part of a DevOps culture is collaboration.
Source: https://www.atlassian.com/devops/what-is-devops/history-of-devops
Patrick Debois Andrew C Shafer
Coined
the Term
in 2009
DevOps

View Slide

DevOps – Lean thinking
177
Source: Sanjeev Sharma, IBM, DevOps for Dummies
Systems of Records: Critical
Enterprise transactions and these
Apps doesn’t require frequent
changes.
Systems of Engagement: With
introduction of Rich Web Apps and
Mobiles Apps, Systems of Records
were augmented by Systems of
Engagements. Customers directly
engage with these Apps and these
Apps requires Rapid Releases.
DevOps Return on Investment
1. Enhanced Customer Experience
2. Increased Capacity to Innovate
3. Faster time to value

View Slide

DevOps
178
Source: https://www.atlassian.com/devops/what-is-devops

View Slide

DevSecOps
179
Source: https://www.atlassian.com/devops/devops-tools/devsecops-tools

View Slide

SAST
180
1. Checkmarx: A comprehensive static code analysis tool that scans source code to
detect vulnerabilities, including SQL Injection, XSS, and more.
2. SonarQube: An open-source platform for continuous inspection of code quality.
It performs automatic reviews with static code analysis to detect bugs, code
smells, and security vulnerabilities.
3. Veracode: A SaaS solution that provides multiple security analysis technologies
on a single platform, including static analysis.
4. Fortify: HP's offering in this space scans source code in several languages and
identifies security vulnerabilities.
5. FindBugs / SpotBugs: A free, open-source SAST tool specifically for Java that
looks for bugs in code. There's a plugin called FindSecBugs that adds security-
specific bug tests.

View Slide

DAST
181
1. OWASP ZAP (Zed Attack Proxy): An open-source DAST tool used for finding
vulnerabilities in web applications while in runtime.
2. Nessus: A widely-used DAST tool specializing in compliance checks, sensitive
data searches, IP scanning, website scanning, etc.
3. Burp Suite: An integrated platform for performing security testing of web
applications. It’s not strictly a DAST tool but is commonly used for manual DAST
work.
4. Arachni: A high-performance open-source tool that helps identify and manage
application security vulnerabilities.
5. AppSpider: A DAST tool by Rapid7 that lets you assess the vulnerabilities and
security of your applications.

View Slide

Management
Pipeline Automation
Design / Develop
SpecOps Workflow - SDLC
182
Green
Field
Brown
Field
Event Sourcing / CQRS
Migration Patterns
Strangler Fig, CDC…
Build
Design Develop Test Stage Ops
Cloud
• Fault Tolerance
• Reliability
• Scalability
• Traffic Routing
• Security
• Policies
• Observability
• Unit Testing
• Component
• Integration
• Contract
• Package
Repositories
• Mvn, npm,
docker hub
• Containers
• Orchestration
• Serverless
• Traffic Routing
• Security (mTLS, JWT)
• Policies (Network / Security
• Observability
Infra Code
• Feature
Code
• Configs
Source Code
Specs

View Slide

183

View Slide

Agile Values
184
INDIVIDUALS AND
INTERACTIONS
OVER PROCESSESS
AND TOOLS
WORKING SOFTWARE
COMPREHENSIVE
DOCUMENTATION
OVER
CUSTOMER
COLLABORATION
OVER CONTRACT
NEGOTIATION
RESPONDING
TO CHANGE
OVER FOLLOWING
A PLAN
Source: Agile Manifesto - https://www.scrumalliance.org/resources/agile-manifesto

View Slide

5 DevOps Principles – CALMS Framework
185
Source: https://www.atlassian.com/devops/frameworks/calms-framework
DevOps isn’t a process,
or a different approach
to development.
It’s a culture change.
DevOps culture is
collaboration.
Build, Test, Deploy, and Provisioning automation
are typical starting points for teams.
Another major contribution of DevOps is
“configuration as code.” Developers strive to
create modular, composable applications
because they are more reliable and maintainable.
CULTURE AUTOMATION
LEAN MEASUREMENT SHARING
Continuous
Improvement
with Canary
Releases and A/B
Testing
Continuous
Improvement
requires Data to
measure the
changes
Sharing responsibility,
success, failure goes a
long way toward
bridging that divide
between Dev and Ops.
You built it, You run it.

View Slide

Implementing CALMS – DevOps Principles
186
Capability Centric Design
Reduce
Organization Silos
CULTURE
Leverage
Tooling &
Automation
Tests, CI/CD Pipeline & Container Orchestration
AUTOMATION
Implement
Gradual
Change
Microservices Architecture
& Agile: Kanban
LEAN
Measure
Everything
Service Mesh: Observability
MEASUREMENT
Accept
Failure as
Normal
Design for Failure
SHARING
Source: IBM DevOps Vs. SRE https://www.youtube.com/watch?v=KCzNd3StIoU Google: https://www.youtube.com/watch?v=uTEL8Ff1Zvk

View Slide

Agile & DevOps
187
Build
Design Develop Test Deploy Ops
Specs
Agile
DevOps
Go Live Support
Specs / Design / Development
CI/CD and Tests Automation
Operations

View Slide

class SRE implements DevOps
o SRE
o Service Levels - SLI / SLO
o SRE Concept
o SRE Responsibilities
188
Source: https://stackify.com/site-reliability-engineering/ - https://www.redhat.com/en/topics/devops/what-is-sre

View Slide

class SRE implements DevOps – CALMS
189
Capability Centric Design
Reduce Organization
Silos
CULTURE
Leverage
Tooling &
Automation
Tests, CI/CD Pipeline & Container Orchestration
AUTOMATION
Implement
Gradual
Change
Microservices Architecture &
Agile: Kanban
LEAN
Measure
Everything
Service Mesh: Observability
MEASUREMENT
Accept
Failure as
Normal
Design for Failure
SHARING
ü Share Ownership
ü SLOs & Blameless PM
ü Canary Deployment, A/B Testing
ü Automate this year’s Job. ü Measure toil & reliability.

View Slide

Service Levels – SLI / SLO
190
SLI – Service Level Indicator
For Web sites:
SLI is a Percentage of requests responded in
good health.
SLI can be a Performance Indicator:
Percentage of search results returned under
50 milli-seconds.
SLO – Service Level Objective
SLO is a goal built around SLI. It is usually a
percentage and is tied to a period and it is
usually measured in a number of nines.
Time periods can be last 24 hours, last
week, last 30 days, current quarter etc.
uptime Last 30 Days
90%
(1 nine of uptime): Meaning you
were down for 10% of the period.
This means you were down for
three days out of the last thirty
days.
99%
(2 nines of uptime): Meaning 1% or
7.2 hours of downtime over the last
thirty days.
99.9%
(3 nines of uptime): Meaning 0.1%
or 43.2 minutes of downtime.
99.99%
(4 nines of uptime): Meaning 0.01%
or 4.32 minutes of downtime.
99.999%
(5 nines of uptime): Meaning 26
seconds or 0.001% of downtime.

View Slide

SRE – Concept
191
q Bridge the Gap between Development & Operations
q Developers wants to ship features as fast as possible
q Operations want stability in Production
q Empowers the Software Developers to own the operations of Applications
in Production.
q Site Reliability Engineers spends 50% of their time in Operations.
q SRE has a deep understanding of the application, the code, how it runs, is
configured and how it will scale.
q They monitor and manage the support apart from the development
activities.

View Slide

SRE – Responsibilities
192
q Proactively monitor and review application performance
q Handle on-call and emergency support
q Ensure software has good logging and diagnostics
q Create and maintain operational runbooks
q Help triage escalated support tickets
q Work on feature requests, defects and other development tasks
q Contribute to overall product roadmap

View Slide

DevOps Best Practices
o Shift Left – CI/CD Automation
o Infrastructure as a Code
o Stages of Delivery Pipeline
o Observability
193

View Slide

Production Environment
Continuous Monitoring
Fully
Automated
Continuous Deployment
Shift Left – Operational Concerns
194
• Operations Concerns move earlier in the software delivery life cycle towards development.
• The goal is to enable Developers and QC Team to Develop and Test the software that behaves like
Production System in a fully automated way.
Development Environment
Build
Build
Build
Test Environment
Continuous Integration
Unit
Testing
Component
Testing
Contract
Testing
Integration
Testing
Continuous Testing
Shift Left moves operations earlier in development cycle.
Stage Environment
Acceptance Testing
Pull Request / Merge
Continuous Delivery
GitOps – CD/CD

View Slide

Infrastructure as a Code
195
• Infrastructure as a Code is a critical
capability for DevOps
• This helps the organizations to
establish a fully automated pipeline
for Continuous Delivery.
• Infra as a Code is a software defined environment to manage the following:
• Network Topologies, Roles, Relationship, Network Policies
• Deployment Models, Workloads, Workload Policies & Behaviors.
• Autoscaling (up & down) of the workloads

View Slide

Stages of DevOps Delivery Pipeline
196
Source: Sanjeev Sharma, IBM, DevOps for Dummies
Application Release Management
Development Build Package
Repository
Test
Environment
Stage
Environment
Production
Environment
Application Deployment Automation
Cloud Provisioning
mvn repository
npm repository
Docker hub

View Slide

Pillars of Observability
197
Immutable records of
discrete events that
happen over time
Logs/events
Numbers describing a
particular process or
activity measured over
intervals of time
Metrics
Data that shows, for
each invocation of each
downstream service,
which instance was called,
which method within that
instance was invoked, how
the request performed, and
what the results were
Traces
Source: A Beginners guide to Observability by Splunk

View Slide

Observability in Kubernetes Worker Node
198
eBPF Programs Network Flow Log
K-Probe
Connection
Tracker
Linux Kernel
Prometheus Envoy Proxy Log Collector FluentD
Pods Pods Pods
Pods Pods Pods
Service
Pods Pods Pods
Pods Pods Pods
Service
Namespace
Pods Pods Pods
Pods Pods Pods
Service
Namespace
Observability Tools

View Slide


View Slide

DevOps Case Studies
• NetFlix
• Spotify
200

View Slide

100s Microservices
1,000s Releases / Day
10,000s Virtual Machines
100K+ User actions / Second
81 M Customers Globally
1 B Time series Metrics
10 B Hours of video streaming every
quarter
Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM
10s OPs Engineers
0 NOC
0 Data Centers
So, what do NetFlix think about DevOps?
No DevOps
Don’t do lot of Process / Procedures
Freedom for Developers & be Accountable
Trust people you Hire
No Controls / Silos / Walls / Fences
Ownership – You Build it, You Run it.
201

View Slide

50M Paid Subscribers
100M Active Users
60 Countries
Cross Functional Team
Full, End to End ownership of features
Autonomous
1000+ Microservices
Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf
1000+ Tech Employees
120+ Teams
202

View Slide

Benefits of DevOps
203
ü Velocity
o Agile / Kanban,
o Capability Centric Design
o Domain Driven Design
o Event Sourcing & CQRS
o Microservices Architecture
Code Build Manage Learn
Idea
ü Quality
o Test Automation
o Build Pipeline Automation
o Continuous Integration
o Continuous Delivery
o Continuous Deployment
o Observability
People Process Tools

View Slide

4
Security Controls & Ops
o Generic Controls
o HIPAA Specific Controls
o PCI-DSS Controls
o DevSecOps
204

View Slide

Generic Controls – 1/7
205
1. Access Controls: Ensuring only authorized individuals can access specific
application parts.
For instance, in the healthcare app, a nurse might have access to update
patient vital signs, while a doctor may have additional access to prescribe
medication. A billing clerk, meanwhile, might have access to billing but
not medical records.
2. Input Controls: These ensure data integrity by validating input.
For example, validating that a patient's Social Security Number or
National Health Service number is in the correct format or that date of
birth entries are reasonable. Input controls would also check for
dangerous code or injections a malicious user might try to input.

View Slide

206
3. Processing Controls: These ensure that the application processes
data correctly.
For example, when prescribing medication, the system checks
whether the patient has any recorded allergies to that medication or
if it interacts with any other currently prescribed drugs.
4. Output Controls: These ensure that the data output from the
application is valid.
For example, when generating a patient's medical history report,
the application should ensure that the report contains accurate and
complete information.

View Slide

207
5. Intrusion Detection/Prevention Controls: These monitor the
application for signs of unusual or suspicious behavior.
For instance, monitoring for failed login attempts, detecting access
to the system from suspicious IP addresses, or identifying if mass
downloads of patient data are occurring.
6. Configuration Management Controls: These ensure that the
application's configuration is secure.
For instance, ensuring that the application's API keys or encryption
keys are not hardcoded into the application but securely managed
or that unnecessary services and ports are disabled on the
application's servers.

View Slide

208
7. Identity and Access Management (IAM) Controls: These controls
are used to authenticate and authorize individuals.
For example, implementing two-factor authentication for all users,
especially those with elevated privileges, and also providing unique
user credentials for each user to ensure accountability.
8. Encryption Controls: These controls are used to protect the
confidentiality and integrity of data.
For example, all patient data should be encrypted at rest (in the
database) and in transit (when sent over the network or accessed
via the application).

View Slide

209
9. Audit and Accountability Controls: These controls ensure
traceability of actions.
For instance, logging who accessed a patient's medical record,
what changes were made, and when. This would be critical in
investigating an incident or for a random audit.
10. Change Management Controls: These are critical in managing
changes in a controlled manner.
For example, any changes to the application, such as software
updates or configuration changes, should go through a formal
approval process, including testing and validation, before
deployment.

View Slide

210
11. Backup and Recovery Controls: These controls ensure data is
regularly backed up and can be recovered.
For example, regular backup of all patient data and a process to
restore from backup in case of data loss, such as a ransomware
attack.
12. Network Security Controls: These controls protect the network
resources associated with an application.
This could involve segmenting the network so that the
application's servers are isolated from less secure parts and
monitoring network traffic for signs of intrusion.

View Slide

211
13. Data Lifecycle Management Controls: These controls manage data
from creation to deletion.
For example, having policies on how long patient data is retained,
how it is securely deleted when no longer needed, and how copies
of the data are controlled.
14. Incident Response Controls: These are preparations for responding
to a security incident.
For instance, having an incident response plan specifically tailored
to potential security incidents, such as a data breach involving
patient information, including specific roles and responsibilities,
communication plans, and recovery measures.

View Slide

HIPAA Controls
Health Insurance Portability and Accountability Act
This U.S. legislation, passed in 1996, provides data privacy and security provisions
for safeguarding medical information. The act contains five sections, or "titles,"
that outline these provisions as well as regulations for health insurance coverage
and tax provisions.
212

View Slide

HIPAA Titles – 1/2
213
1. Title I: Health Care Access, Portability, and Renewability:
This title makes it easier for people to keep health insurance, protects the
confidentiality and security of healthcare information, and helps the healthcare
industry control administrative costs. It restricts pre-existing condition exclusions
and allows a new employer's plan to count coverage under the old employer's
plan.
2. Title II: Preventing Health Care Fraud and Abuse; Administrative Simplification;
Medical Liability Reform:
Also known as the "Administrative Simplification" provisions, Title II requires
establishing national standards for electronic health care transactions and
national identifiers for providers, health insurance plans, and employers. This
includes the Privacy and Security Rule, which sets standards for protecting the
privacy and security of individually identifiable health information.

View Slide

HIPAA Titles – 2/2
214
3. Title III: Tax-Related Health Provisions Governing Medical Savings Accounts:
This title includes tax-related provisions and guidelines for medical care,
including provisions about company-owned life insurance and the treatment of
individuals who lose U.S. citizenship for income tax purposes.
4. Title IV: Application and Enforcement of Group Health Plan Requirements:
This title further defines health insurance reform, including provisions for
individuals with pre-existing conditions and those seeking continued coverage.
5. Title V: Revenue Offsets:
This title includes provisions on company-owned life insurance and the
treatment of those who lose U.S. citizenship for income tax purposes. It also has
a provision governing the income tax deduction for the health insurance costs of
self-employed individuals.

View Slide

HIPAA Controls: Title II – 1/4
215
1. Access Control: HIPAA requires that only authorized individuals should have
access to electronic protected health information (e-PHI). It mandates unique
user identification, emergency access procedure, automatic logoff, encryption,
and decryption.
For example, in a healthcare application, only authorized personnel (like a
particular doctor or nurse) should have access to the medical records of the
patients they are treating. This can be ensured through unique login credentials
for each user.
2. Audit Control: HIPAA requires hardware, software, and/or procedural
mechanisms that record and examine activity in information systems that
contain or use e-PHI.
For instance, an audit log in an electronic health record system might record
when patient records are accessed, who accessed them, what changes were
made, and when.

View Slide

HIPAA Controls : Title II – 2/4
216
3. Integrity Control: HIPAA states that e-PHI should not be improperly
altered or destroyed. Electronic measures must be implemented to
confirm that e-PHI has not been improperly altered or destroyed.
For example, using checksums or hashes can help ensure that data
hasn't been tampered with. Additionally, backup and disaster
recovery procedures can help prevent data loss.
4. Transmission Security: e-PHI transmitted over a network must be
protected against unauthorized access. It includes integrity controls
and encryption that were deemed appropriate.
For example, when transmitting e-PHI over the internet, SSL/TLS
encryption could secure the data during transit.

View Slide

HIPAA Controls : Title II – 3/4
217
5. Person or Entity Authentication: HIPAA requires procedures to
verify that a person or entity seeking access to e-PHI is the one
claimed.
For example, this could be done through strong passwords, two-
factor authentication, or biometric identification methods.
6. Risk Analysis and Management: The HIPAA Security Rule requires
covered entities to conduct a risk analysis to identify risks and
vulnerabilities to e-PHI and to implement security measures to
mitigate those identified risks.
This might involve conducting regular security audits, vulnerability
assessments, and penetration testing to identify potential
vulnerabilities or compliance gaps.

View Slide

HIPAA Controls: Titles II – 4/4
218
7. Training and Awareness: HIPAA requires regular training of all employees
who handle PHI to ensure they understand the regulations and the
importance of protecting health information.
For example, staff might be trained on the correct handling of PHI,
identifying phishing attempts, and the correct response to a suspected or
confirmed data breach.
8. Incident Response and Reporting: In case of a security incident, HIPAA
mandates the identification and response to suspected or known security
incidents, mitigation to the extent practicable, and documentation of
incidents and their outcomes.
For instance, if a data breach occurs, it's essential to have a plan in place
to identify and control the breach, assess the damage, notify affected
individuals, and prevent future occurrences.

View Slide

PCI-DSS Controls
Payment Card Industry Data Security Standard
The PCI-DSS standard is governed by the PCI Security Standards Council, which was
founded by American Express, Discover Financial Services, JCB International,
MasterCard, and Visa Inc.
219

View Slide

PCI-DSS Controls – 1/3
220
1. Build and Maintain a Secure Network and Systems
1. Requirement 1: Install and maintain a firewall configuration to
protect cardholder data.
2. Requirement 2: Do not use vendor-supplied defaults for system
passwords and other security parameters.
2. Protect Cardholder Data
1. Requirement 3: Protect stored cardholder data.
2. Requirement 4: Encrypt transmission of cardholder data across
open, public networks.

View Slide

221
3. Maintain a Vulnerability Management Program
1. Requirement 5: Protect all systems against malware and update
antivirus software or programs regularly.
2. Requirement 6: Develop and maintain secure systems and applications.
4. Implement Strong Access Control Measures
1. Requirement 7: Restrict access to cardholder data by business need to
know.
2. Requirement 8: Identify and authenticate access to system
components.
3. Requirement 9: Restrict physical access to cardholder data.

View Slide

222
5. Regularly Monitor and Test Networks
1. Requirement 10: Track and monitor all access to network
resources and cardholder data.
2. Requirement 11: Regularly test security systems and
processes.
6. Maintain an Information Security Policy
1. Requirement 12: Maintain a policy that addresses
information security for all personnel.

View Slide

DevSecOps
223
o DevOps (IEEE P2675)
o DevSecOps Concepts
o DevSecOps Pipeline
o SAST vs DAST
o Risk Management Framework
o cATO
o DevSecOps Playbook

View Slide

DevOps (IEEE P2675)
224
DevOps is a set of principles and practices emphasizing collaboration &
communication between Software Development Teams and IT Operations Staff along
with acquires, suppliers, and other stakeholders in the lifecycle of a Software System.
5
o Collaboration: between all Stakeholders
o Infrastructure as a Code: Assets are versioned,
scripted, & shared
o Automation: Deployment, Testing, Provisioning,
any manual or human-error-prone process
o Monitoring: Any metric in Development or
Operation that can inform priorities, direction
and policy.
Source: IEEE P2675-2021 IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment:
Standardising Change: IEEE P2675 DevOps Standard (Ruth G. Lennon) https://www.youtube.com/watch?v=a3E0u48lYyM
Five Principles of DevOps
1. Mission First
2. Customer Focus
3. Left Shift
4. Continuous Everything
5. System Thinking
ü Focuses on establishing effective Compliance and IT Controls

View Slide

DevSecOps
225
DevSecOps is a culture and philosophy that
must be practiced across the organization,
realized through the unification of a set of
Software development (Dev), Security (Sec)
and Operations (Ops) personnel into a
singular team.
Source: Page 17. US DoD Enterprise DevSecOps 2.0 Fundamentals

View Slide

DevSecOps Manifesto
226
Source: https://www.devsecops.org/
1. Leaning in over Always Saying “No”
2. Data & Security Science over Fear, Uncertainty and Doubt
3. Open Contribution & Collaboration over Security-Only Requirements
4. Consumable Security Services with APIs over Mandated Security Controls & Paperwork
5. Business Driven Security Scores over Rubber Stamp Security
6. Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities
7. 24x7 Proactive Security Monitoring overreacting after being Informed of an Incident
8. Shared Threat Intelligence over Keeping Info to Ourselves
9. Compliance Operations over Clipboards & Checklists

View Slide

DevSecOps
227
Source: https://www.atlassian.com/devops/devops-tools/devsecops-tools

View Slide

DevSecOps
228
Recommended by US DoD DevSecOps Best Practices
Source:
Page 17
US DoD
Enterprise
DevSecOps
Fundamentals

View Slide

DevSecOps Pipeline
229
Source: US DoD DevSecOps Fundamentals Guidebook. Page 6

View Slide

SAST vs DAST
230
Source: https://www.synopsys.com/blogs/software-security/sast-vs-dast-difference/
White box security testing
The tester has access to the underlying framework, design,
and implementation. The application is tested from the
inside out. This type of testing represents the developer
approach.
Black box security testing
The tester has no knowledge of the technologies
or frameworks that the application is built on.
The application is tested from the outside in. This
type of testing represents the hacker approach.
Requires source code
SAST doesn’t require a deployed application. It analyses the
sources code or binary without executing the application.
Requires a running application
DAST doesn’t require source code or binaries.
It analyses by executing the application.
Finds vulnerabilities earlier in the SDLC
The scan can be executed as soon as code is deemed
feature-complete.
Finds vulnerabilities toward the end of the SDLC
Vulnerabilities can be discovered after the
development cycle is complete
Can’t discover run-time and environment-related issues
Since the tool scans static code, it can’t discover run-time
vulnerabilities.
Can discover run-time and environment-related
issues
Since the tool uses dynamic analysis on an
application, it is able to find run-time
vulnerabilities.

View Slide

Risk Management Framework
231
NIST SP 800-37 Rev.2
Source: NIST https://csrc.nist.gov/projects/risk-management/about-rmf : NIST 800-37
0. Prepare
Essential activities to prepare the
organization to manage security
and privacy risks
1. Categorize Information System
Categorize the system and information
processed, stored, and transmitted
based on an impact analysis.
2. Select Controls
Select the set of NIST SP 800-53
controls to protect the system
based on risk assessment(s)
3. Implement Controls
Implement the controls and
document how controls are deployed
4. Assess Controls
Assess to determine if the controls are
in place, operating as intended, and
producing the desired results
5. Authorize System
Senior official makes a risk-based decision
to authorize the system (to operate)
6. Monitor Controls
Continuously monitor control
implementation and risks to the
system

View Slide

DevSecOps Playbook
US DoD Enterprise DevSecOps 2.0 Playbook
232

View Slide

6
DevSecOps Playbook
233
1 Adopt a DevSecOps Culture
2 Adopt Infrastructure as Code
3 Adopt Containerized
Microservices
4 Adopt a Capability Model, not a
Maturity Model
5 Drive Continuous Improvement
through Key Capabilities
Establish a Software Factory
7 Define a meaningful
DevSecOps pipeline
8 Adapt an Agile Acquisition
Policy for Software
9 Tirelessly Pursue Cyber
Resilience
10 Shift Left: Operational Test &
Eval
Source: US DoD DevSecOps Fundamentals Playbook

View Slide

Adopt a DevSecOps Culture
234
1
Key Cultural Practices
1. Stakeholder transparency and visibility.
2. Complete transparency across team members in real-
time.
3. All project resources easily accessible to the entire team;
not everyone needs commit privileges.
4. Adopt and embrace ChatOps as the communication
backbone for the DevSecOps team.
5. All technical staff should be concerned with, and have a
say in, baked-in security.
Source: US DoD DevSecOps Fundamentals Playbook. Page 4

View Slide

Adopt Infrastructure as Code
235
2
Key Advantages
1. IT infrastructure supports and enables change, rather than being an obstacle
or a constraint.
2. Mitigates drift between environments by leveraging automation and push-
button deployment.
3. Enforces change management through GitOps with multiple approvers, as
needed.
4. Environmental changes are routine and fully automated, pivoting staff to focus
on other tasks.
5. Quicker recovery from failures, rather than assuming failure can be completely
prevented.
6. Empowers a continuous improvement ecosystem rather than “big bang” one
and done activities.

View Slide

Adopt Containerized Microservices
236
3
Components
via
Services
Organized around
Business
Capabilities
Products
NOT
Projects
Smart
Endpoints
& Dumb Pipes
Decentralized
Governance &
Data Management
Infrastructure
Automation
via IaC
Design for
Failure
Evolutionary
Design

View Slide

Adopt a Capability Model, not a Maturity Model
237
4
Metric High Performers Medium Performers Low Performers
Deployment frequency –
How often the organization deploys
code.
On demand (multiple
deploys per day)
Between once per
week and once per
month
Between once per
week and once per
month
Change lead time –
Time it takes to go from code commit to
code successfully running in production.
Less than one hour Between one week
and one month
Between one week
and one month
Mean time to recover (MTTR) –
Time it takes to restore service when a
service incident occurs (e.g., unplanned
outage, service impairment).
Less than one hour Less than one day Between one day and
one week
Change failure rate –
Percentage of changes that results in
either degraded service or requires
remediation (e.g., leads to service
impairment, service outage, requires a
hotfix, rollback, patch, etc.)
0-15% 0-15% 31-45%
Google’s DORA research program advocates that rather than use a maturity
model, research shows that a capability model is a better way to both
encourage and measure performance improvement

View Slide

Drive Continuous Improvement through Key Capabilities
238
5
Architecture
1. Use Loosely Coupled Architecture
2. Architect for Empowered Teams
Culture
1. Adopt a Likert scale survey to
measure cultural change progress
2. Encourage and support continuous
learning initiatives
3. Support and Facilitate
Collaboration among and between
teams
4. Provide resources and tools that
make work meaningful
5. Support or Embody
transformational leadership
24 There are 24 Key that drive
improvements across both
DevSecOps and the
Organization
5 Classified into 5 Categories
1. Culture
2. Architecture
3. Product & Process
4. Continuous Delivery
5. Lean Management &
Monitoring

View Slide

Drive Continuous Improvement through Key Capabilities
239
5
Continuous Delivery
1. Use a Source Code Repo for all production Artifacts
2. Use Trunk based development methods
3. Shift Left on Security
4. Implement Test Automation
5. Implement Continuous Integration
6. Support Test Data Management
7. Implement Continuous Delivery
8. Automate the Deployment Process
Product and Process
1. Gather and Implement Customer Feedback
2. Make the flow of work visible through the value
stream
3. Work in small batches
4. Foster and enable team experimentation
Lean Management & Monitoring
1. Have a lightweight change
approval process
2. Monitor across applications &
infrastructure too inform
business decisions
3. Check System Health periodically
4. Improve Processes and Manage
work with WIP
5. Visualize work to Monitor quality
and communicate throughout

View Slide

Establish a Software Factory
240
6
• Define CI/CD Processes
and Tasks
• Select Tools
• Operate & Maintain the
Software Factory
• Monitor the Tools and
Processes
• Gather Feedback for
Improvement
• Build the Software
Factory
• Automate the
Workflows
• Verify the Tool
Integrations
• Test the Pipeline
Workflows

View Slide

Define a meaningful DevSecOps pipeline
241
7

View Slide

Adapt an Agile Acquisition Policy for Software
242
8
• Establishes the Software Acquisition Pathway as the
preferred path for acquisition and development of
software-intensive systems.
• Simplifies the acquisition model to enable continuous
integration and delivery of software capability on timelines
relevant to the warfighter / end user.
• Establishes business decision artifacts to manage risk and
enable successful software acquisition and development.

View Slide

Tirelessly Pursue Cyber Resilience
243
9
• Cyber Resilience is “the ability to anticipate, withstand, recover from, and
adapt to adverse conditions, stresses, attacks, or compromises on the
systems that include cyber resources.”
• Cybersecurity touches each of the eight phases of the DevSecOps
lifecycle, and the various control gates serve as Go/No-Go decision
points.
• Al pipelines must use these control gates to ensure that cybersecurity is
both “baked in” and transparently identified
• Moving to DevSecOps includes moving towards a Continuous
Authorization to Operate (cATO) for an application developed using
DevSecOps processes, including a software factory with a CI/CD pipeline.

View Slide

Shift Left: Operational Test & Eval
244
10
Common Testing Categories
1. Unit and Functional Testing.
2. Integration Testing.
3. Performance Testing.
4. Interoperability Testing.
5. Deployment Testing (normally conducted in a staging environment).
6. Operational Testing (normally conducted in a production environment).
7. Static Application Security Testing (SAST).
8. Dynamic Application Security Testing (DAST).
9. Interactive Application Security testing (IAST).
10. Runtime Application Self-Protection (RASP).

View Slide

5
Code Setup
o SpringBoot 2.7.2
o Java 8 for Compile and Java 17 to run
o H2 DB or PostgreSQL database
245

View Slide

Package Structure
246
Source:
https://github.com/arafkarsh
https://github.com/arafkarsh/ms-springboot-272-vanilla

View Slide

247

View Slide

248

View Slide

How to Test the Vulnerabilities
249
By default, all the
vulnerabilities are
disabled, and those
APIs will give the
following Security
Exceptions.
“Vulnerability API
Demos are DISABLED!
Please Check the
Configuration.”
Change the following
properties in the
application properties file.
server.vulnerability.demos.
allowed=false

View Slide

5
o Cross-Site Scripting Vulnerability (XSS)
o Input Validation and XSS
o Buffer Overflow Exploit
o Directory Traversal Exploit
250
Source: https://github.com/arafkarsh/ms-springboot-272-vanilla
o Command / Shell Injection Exploit
o Vulnerable and Outdated Components
o HTTP Response Split Vulnerability

View Slide

1. Cross-Site Scripting (XSS)
251
Cross-Site Scripting (XSS) attacks occur
• when an attacker uses a web application to send the malicious script,
• Generally in the form of a browser-side script to a different end user.
• The end user’s browser cannot know that the script should not be trusted
• and will execute the script.
• XSS attacks can lead to various problems, including stolen session tokens or login
credentials, defacement of websites, or malicious redirection.
For example, if a website echoes back whatever is passed in the URL as a parameter
without sanitizing it, an attacker might pass in something like
http://www.example.com/?q=/*malicious code*/, leading to the
script being executed on the victim's browser.
Countermeasures include validating and sanitizing input, encoding output, and
using Content Security Policy (CSP) headers to prevent scripts from loading from
unauthorized sources.

View Slide

1. Vulnerable Code
252
Source: https://github.com/arafkarsh/ms-springboot-272-vanilla
No validations OR sanitizing the input

View Slide

1. Testing the Vulnerability
253

View Slide

1. Code Fix: Sanitize the data
254

View Slide

1. Code Fix: Limit the Data / Content
255

View Slide

1. Code Fix: DB Constraints (Size Limit)
256

View Slide

1. Code Fix – Content Security Policy
257
Spring Security Policy

View Slide

Types of XSS
258
Stored XSS
Stored XSS, also known as persistent XSS, occurs when malicious input provided by an attacker is
stored on the target server, such as in a database, message forum, comment field, etc. The
malicious content is then permanently part of the target server's content, and the stored code is
executed every time a user requests the stored information.
Example: An attacker submits a comment on a blog with a script. Every time a user views that
comment, the script runs.
Reflected XSS
Reflected XSS occurs when an attacker injects malicious input into a URL, which is then reflected
off a web application onto a user's browser. This malicious content is part of the response sent by
the server but is not stored on the server itself. The victim must visit the manipulated URL for the
script to be executed.
Example: An attacker sends a link with a malicious script embedded in the URL parameters. The
unsuspecting victim clicks on the link, and the server reflects the script back to the user's browser,
where it is executed.

View Slide

Types of XSS
259
DOM-based XSS
DOM-based XSS is a form of XSS where the entire tainted data flow from source to sink occurs in the browser,
i.e., within the Document Object Model (DOM). Unlike reflected and stored XSS, where the server's response
includes the attack payload, a DOM-based XSS attack is entirely contained within the client's browser.
Example: A web page reads a URL fragment (after '#') and writes it to the page without proper sanitization. An
attacker can craft a URL with a script in this fragment, and when a victim navigates to it, the script is executed
within the browser.
Content XSS
Content XSS is not a widely recognized or standardized category of XSS, and its definition can vary depending
on context. It might refer to an attack where malicious content (such as misleading text or links) is inserted into
a web page without necessarily including executable script code.
In some contexts, Content XSS might be an umbrella term or misnomer encompassing one or more XSS types
listed here.
These different types of XSS demonstrate the variety of ways in which attackers can exploit users’ trust in a
particular website. The defenses against XSS typically involve proper input validation, sanitization, and
escaping, along with security mechanisms like Content Security Policy (CSP).

View Slide

2. Input Validation and XSS
260
Input validation is critical to prevent various kinds of
attacks, including XSS. It involves ensuring that the
input the user provides meets specific criteria, such as
length, type, and format, before processing it.
For example, an application might
• restrict the length of a user's name to 50 characters,
• disallow special characters, and
• require that the email address is in a valid format.
Any input must meet these criteria to be accepted.

View Slide

2. Vulnerable Code: DTO
261
No Input Validation for any
of the fields apart from
Null Check.
For Example,
1. Customer ID should
have a max length and
validate the data.
2. Product ID should have
max length and validate
the data.
3. The product Name
should have min and
max length and validate
the data.

View Slide

2. Vulnerable Code: Entity
262
No Input Validation for any of the fields apart
from Null Check.
For Example,
1. Customer ID should have a max length and
validate the data.
2. Product ID should have max length and
validate the data.
3. The product Name should have min and
max length and validate the data.

View Slide

2. Code Fix: Entity
263

View Slide

2. Code Fix: DB Constraints (Size Limit)
264

View Slide

3. Buffer Overflow Exploit
265
Buffer overflow vulnerabilities typically manifest in languages like C or
C++, where memory management is manual and the language does not
enforce bounds checking.
Java, the language that Spring Boot is based on, has built-in bounds
checking for array and buffer accesses, making classic buffer overflow
exploits extremely rare.
In the web application context, we can still discuss improper handling of
significant inputs or unexpected data sizes that may lead to resource
exhaustion, unresponsive systems, or other unforeseen behavior.
It’s not precisely a buffer overflow in the traditional sense, but managing
the size and content of data is still a critical aspect of secure
programming.

View Slide

3. Vulnerable Code: Cart Model
266
No Input Validation for any of the fields apart
from Null Check.
For Example,
1. Customer ID should have a max length.
2. Product ID should have max length.
3. The product Name should have min and
max.
4. Price is Nullable
5. Quantity is Nullable

View Slide

3. Code Fix: Cart Model
267

View Slide

3. Bounds Check in Java
268
1. Array Indexing: In languages like C and C++, if you try to access or modify an element at an index outside
the bounds of an array, the behavior is undefined, and it might lead to overwriting adjacent memory. In
contrast, Java automatically checks if the index is within the array's bounds. If it's not, a
java.lang.ArrayIndexOutOfBoundsException is thrown.
Example:
int[] intArray = new int[10];
intArray[10] = 5; // Throws ArrayIndexOutOfBoundsException
2. Buffer Classes: Java’s Buffer classes, like ByteBuffer, also include bounds checking. If you attempt to
read or write to a position outside the buffer's limits, a BufferUnderflowException or
BufferOverflowException will be thrown, respectively.
3. String Manipulation: Even when dealing with strings and their manipulation, Java maintains the
boundaries. Trying to access a character at an index outside the length of the string will result in a
StringIndexOutOfBoundsException.

View Slide

4. Directory Traversal Exploit
269
Directory traversal attacks involve exploiting:
• Insufficient security validation/sanitization of user-supplied
input file names
• so that characters representing "traverse to parent
directory" are passed through to the file APIs.
• This could allow the attacker to read or write files outside
the intended directory.
Countermeasures involve validating and sanitizing input,
implementing secure error handling, and adhering to the
principle of least privilege.

View Slide

4. Vulnerable Code: File Handling
270
This code can read
any File in the
System.

View Slide

4. Code Fix: File Handling
271

View Slide

5. Command / Shell Injection Exploit
272
Command Injection Vulnerability, Shell Injection, or OS
Command Injection, is an injection vulnerability where
an attacker can execute arbitrary commands on the
host operating system through a vulnerable application.
This kind of vulnerability arises when input provided by
the user is improperly sanitized before being passed to
a system command.

View Slide

5. Command / Shell Injection: How it works
273
1. User Input in System Command: Applications sometimes need to
run system commands. If any part of the command depends on
user input, and if that input is not correctly validated, an attacker
may be able to manipulate the command.
2. Attacker Control: By adding special characters, such as semicolons,
ampersands, and others that have special meaning in shell
commands, an attacker can append additional commands to be
executed.
3. Result: The attacker’s commands are executed with the same
privileges as the vulnerable application. Depending on the
application’s permissions, this could lead to various malicious
activities.

View Slide

5. Vulnerable Code
274
http://localhost:9089/ms-vanilla/api/v1/security/vulnerable/cmd/readFile?_fileName=publicKey.pem; ls -la

View Slide

5. Code Fix: Use Process Builder
275
This secure version uses ProcessBuilder, passing the filename parameter as an
argument, which avoids the risk of command injection. Even if the filename
contains shell metacharacters, the shell won’t interpret them, preventing
Command / Shell injection.

View Slide

6. Vulnerable and Outdated Components
276
CVE-2016-1000027
Pivotal Spring Framework through 5.3.16
suffers from a potential remote code
execution (RCE) issue if used for Java
deserialization of untrusted data.
Depending on how the library is
implemented within a product, this issue
may or not occur, and authentication may
be required.
NOTE: the vendor believes untrusted data is
not an intended use case. The product’s
behavior will remain unchanged because
some users rely on deserializing trusted
data.
Source: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000027
Source: https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web/2.7.2

View Slide

6. Code Fix: Update Component Version
277
Source: https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web/3.1.2

View Slide

7. Http Response Splitting Vulnerability
278
HTTP Response Splitting is an attack that takes advantage of
how HTTP headers are processed. By injecting newline
characters into HTTP header values, an attacker can create
additional HTTP headers and even wholly separate HTTP
responses, thereby manipulating the HTTP process on the
client side.
Example: Imagine a healthcare app with a patient’s name in a
response header. An attacker might manipulate the response
by injecting malicious characters into the patient's name.

View Slide

7. Attackers Approach
279
Imagine there's a form on the healthcare app where a patient can update their profile information,
including their name. The attacker alters their patient name to include newline characters and HTTP
header content.
For example, instead of simply entering "John Smith" as the patient's name, they enter:
John\r\nContent-Length: 0\r\n\r\nalert('Hacked!');
HTTP/1.1 200 OK
Set-Cookie: patient=John
Content-Length: 0
alert('Hacked!');
Other-Headers: other-values
How the Attack Works with the Vulnerable Code
When this input is sent to the server, and if the server
doesn't properly validate or escape the input, the server
might process this as part of the HTTP response, adding an
additional header and HTML content to the HTTP response.
The server's response could end up looking like this:
This means that when the response is rendered in the user's browser, the JavaScript code will
execute, potentially leading to further exploits, such as stealing the user's cookies or performing
actions on behalf of the user.

View Slide

7. Vulnerable Code
280
No Checks were performed in the input “customerId.”

View Slide

7. Code Fix: Validating Cookies
281

View Slide

7. Code Fix: Validating Cookies
282

View Slide

7. Understanding Cookie paramters
283
1. HttpOnly: This attribute ensures that the cookie is not accessible via JavaScript.
It significantly reduces the risk of a stolen cookie through cross-site scripting
(XSS) attacks.
2. Secure: Ensures the cookie is sent only over HTTPS, not unencrypted HTTP. This
attribute is crucial to avoid man-in-the-middle attacks where an attacker might
intercept or alter your HTTP requests/responses.
3. Max-Age: This attribute specifies the lifetime of the cookie in seconds. After this
duration, the cookie will be deleted. This ensures that a potential attacker has
only a limited time window to exploit a stolen cookie.
4. Path: Specify the URL path in the requested URL to send the Cookie header.
Limiting the path reduces the places where the cookie can be sent, providing
more control.

View Slide

7. Understanding Cookie paramters
284
5. SameSite: This attribute mitigates cross-site request forgery (CSRF)
attacks. There are three possible values:
1. Strict:
The browser sends the cookie back to the server only when requests are
made to the same site that set the cookie and not for cross-site requests.
2. Lax:
The browser does not send cookies for cross-site subrequests (like loading
images or frames). However, the cookie will be sent back to the server if the
user navigates directly to the site that set the cookie (from an external link,
for example).
3. None:
The browser will send the cookie back to the server in all contexts, including
both first-party and third-party requests.

View Slide

7. Understanding Same-Site Param
285
1. Strict:
• Description: The cookie will only be sent in first-party contexts.
This means that the cookie will only be included in requests if
made to the same site that set the cookie.
• Example:
• If you visit https://example.com and that site sets a cookie with
SameSite=Strict, that cookie will only be sent with requests that
go to https://example.com.
• If another site, say https://another-site.com, tries to load a
resource from https://example.com, the cookie will not be
included in the request.

View Slide

286
2. Lax:
• Description: The cookie is withheld on cross-site subrequests (like
loading images or frames into a third-party site), but is sent when a
user navigates to the URL from an external site, such as by
following a link.
• Example: Imagine you have an account on a social media site,
https://social.com, which sets a cookie with SameSite=Lax.
• If you visit another site, https://news.com, which has an embedded
widget from https://social.com, the cookie will NOT be sent with
the request to load that widget. However, if you follow a link on
https://news.com that leads directly to https://social.com, the
cookie will be sent with that request.

View Slide

287
3. None:
• Description: The cookie will be sent in all contexts i.e. with first-party
and third-party requests.
• Example: Let's use https://example.com again.
• If it sets a cookie with SameSite=None, it will be sent regardless of
where the request comes from. So, if https://another-site.com
requests https://example.com, the cookie will be included. This
behavior is how cookies worked traditionally before the SameSite
attribute was introduced.
• Note: When using SameSite=None, you must also set the Secure
attribute on the cookie to ensure it's only sent over HTTPS
connections.

View Slide

6
o Parameter Manipulation Vulnerability
o SQL Injection Vulnerability
o XML Injection / XML Entity
o XPath Injection
288
o Cross-Site Request Forgery (CSRF)
o Server-Side Request Forgery (SSRF)
o Spring Security

View Slide

8. Parameter Manipulation Vulnerability
289
Parameter Manipulation is an attack where an attacker
alters parameters sent between the client and the
server to gain unauthorized access to data or perform
actions they aren't permitted to perform.
Example: Consider a healthcare app where patients can
view their medical records. An attacker might alter the
patient ID parameter to access someone else's records.

View Slide

8. Vulnerable Code
290

View Slide

8. Code Fix: Authorization Enabled
291

View Slide

9. SQL Injection Vulnerability
292
SQL Injection is one of the most common and dangerous web application
vulnerabilities. It occurs when an attacker can inject arbitrary SQL code into a
query, which is then executed by the database. This can lead to various malicious
outcomes, including unauthorized viewing of data, corrupting or deleting data, and
in some cases, even complete control over the host machine.
Example: In the context of healthcare, this vulnerability is severe. Medical records
are highly sensitive, and unauthorized access could lead to identity theft, fraud, or
harm. Additionally, healthcare organizations are bound by regulations such as
HIPAA in the U.S., which mandates strict controls over the confidentiality, integrity,
and availability of health information. A breach through SQL Injection could lead to
significant legal penalties, reputational damage, and loss of trust among patients
and partners. Therefore, employing proper security measures is not just a technical
issue but a legal and ethical imperative.

View Slide

9. How it works
293
1. How it Happens:
SQL Injection typically occurs when user input is improperly sanitized and then
used in a SQL query. By crafting the input in a specific way, an attacker can
manipulate the query's structure, often breaking out of the intended context
and executing arbitrary SQL statements.
2. Types of SQL Injection:
1. In-Band SQL Injection: Data is extracted using the same communication
channel that is used to inject the SQL code.
2. Out-of-Band SQL Injection: Data is retrieved using a different
communication channel.
3. Blind SQL Injection: No data is transferred, and the attacker determines if
the hypothesis is true based on the application's response.

View Slide

9. Blind SQL Injection
294
1. Boolean-Based Blind SQL Injection
In this type of injection, the attacker sends a SQL query to the database, forcing the
application to return a different result depending on whether the query returns
true or false.
An attacker might input a string like "1' OR '1'='1", forcing the query always to
return true.
2. Time-Based Blind SQL Injection
In this attack, the attacker determines if the hypothesis is true based on how long
the application takes to respond. The SQL statement forces the database to wait for
a specified time before responding.
An attacker could use a payload like "admin' OR IF(1=1, SLEEP(5), 0)--". If the
condition is true, the database will wait for 5 seconds before responding.

View Slide

9. Counter Measures
295
1. Prepared Statements: By using prepared statements with parameterized
queries, you can ensure that user input is always treated as data and not
executable code.
2. Stored Procedures: Similar to prepared statements, stored procedures
separate SQL code from user input.
3. Input Validation: Implement strict validation on user input to reject any
suspicious or unexpected input.
4. Least Privilege Principle: Limit the permissions of the database user
account to minimize potential damage.
5. Error Handling: Customize error messages to prevent leaking information
about the database structure, which could aid an attacker.

View Slide

9. SQL IN-Band Injection
296

View Slide

9. SQL IN-Band Injection: Code Fix
297

View Slide

9. SQL Out-of-Band Injection
298
Exploiting via Database Notification Functionality
Imagine an application that uses a query to send email notifications based on user input:
Exploit
jane.doe'; DROP TABLE ms_schema.critical_table_tx; --

View Slide

9. SQL Out-of-Band Injection: Code Fix
299

View Slide

9. Vulnerable Code: Blind SQL Injection
300
Exploit: jane.doe' OR '1'='1
http://localhost:9089/ms-vanilla/api/v1/security/vulnerable/cart/sql/customer/ jane.doe%27%20OR%20%271%27%3D%271
Boolean-Based SQL Injection

View Slide

9. Code Fix: Using Bind Variables
301

View Slide

9. Spring: Enabling Strict Firewall
302
Features of the StrictHttpFirewall:
1. Blocked HTTP Methods: By default, it allows only GET, POST, HEAD, OPTIONS,
and TRACE methods, blocking others like PUT, DELETE, etc. This is to ensure that
only typical browser methods are allowed.
2. URL Decoding: StrictHttpFirewall prevents multiple URL decoding attempts,
which can be an attack vector.
3. URL ; (semicolon) blocking: By default, it will block URLs that contain a
semicolon. This defends against attacks like request parameter pollution.
4. URL // (double slash) blocking: Prevents URLs with double slashes.
5. URL Backslash \ blocking: By default, backslashes are blocked.
6. URL % (percent) blocking: It can be configured to block URLs with URL-encoded
values.

View Slide

9. Spring: StrictFirewall Code
303

View Slide

9. Spring: Web Security
304
Web Security is a
crucial element that
provides security
configuration at the
web application
level, enabling you
to apply security to
specific URL
patterns, HTTP
verbs, etc.
The Web Security
Configurer Adapter
class allows
developers to
conveniently
provide custom
web security
configurations.

View Slide

10. XXE – XML Entity Injection Vulnerability
305
XML Injection, also known as XML Entity Injection, is an attack technique used to
manipulate or compromise the logic of an XML application or service. The attacker
injects malicious content into XML data, which can result in the disclosure of
confidential data, denial of service, port scanning from the perspective of the
machine where the parser is located, and other system impacts.
1. XML Injection can cause the XML parser to access unintended data or execute remote commands.
2. XML Injection can lead to the disclosure of confidential data, denial of service, server-side request
forgery, port scanning from the perspective of the machine where the parser is located, and other
system impacts.
3. XML Injection can bypass authentication or authorization functions or act as a stepping-stone toward
other attacks.
4. XML Injection can be used to modify SOAP message routing and message content and/or alter
intended service behavior.
5. XML Injection can access local or remote files and services through XML messages.
6. XML Injection can be used to execute remote commands.

View Slide

10. XXE – XML Injection: How it works
306
1. Entity Declaration: XML supports the declaration of entities. An
entity can be used to represent specific data within the XML
document.
2. Entity Expansion: Once declared, these entities can be used
elsewhere in the XML document by referencing their names. If the
XML parser is configured to expand these entities, the entity's value
will replace its reference in the document.
3. External Entities: One hazardous feature of XML entities is that
they can be defined to fetch remote content. This allows an
attacker to specify an external domain or resource from which the
XML parser will fetch data.

View Slide

10. XML Injection: Common Impacts
307
1. Disclosure of Confidential Data: By using external entities, an attacker can make the
XML parser fetch content from within the internal network of the application,
potentially disclosing sensitive information.
2. Denial of Service (DoS): This can be achieved using the "Billion Laughs Attack." The
attacker defines an entity that refers to itself multiple times, causing exponential growth
of the processed XML and consuming system resources to the point of system failure.
3. Server-Side Request Forgery (SSRF): Attackers can use external entities to force the
XML parser to request internal resources, potentially leading to the disclosure of
internal content or even remote command execution in specific vulnerable systems.
4. Port scanning: From the server’s perspective, the attacker can craft unique XML
payloads to discover and probe internal ports.
5. Potential Remote Code Execution: In some vulnerable systems, it might be possible to
execute arbitrary code by exploiting misconfigurations or utilizing certain features.

View Slide

10. XML Injection: Counter Measures
308
1. Disable External Entities: Most XML parsers allow external entities to be disabled. This should
be the default setting unless there's a specific need.
2. Use Less Complex Data Formats: Opt for simpler data formats like JSON whenever possible.
However, remember that JSON parsers can have their vulnerabilities (although not entity-
related).
3. Update and Patch: Keep XML libraries and parsers updated. Vulnerabilities are always
discovered in software libraries; keeping them updated ensures you’re protected against known
issues.
4. Input Validation: Use whitelisting instead of blacklisting to ensure that only expected and safe
content is processed.
5. Use Sandboxing: If XML parsing is needed and can't be avoided, run the parsing process in a
sandboxed environment to reduce the potential harm of an exploit.
6. Limit Resources: Limit the resources (CPU, RAM) that an XML parser can use to protect against
DoS attacks.
7. Web Application Firewalls (WAFs): Employ a WAF to detect and block XML injection attempts

View Slide

10. XML Injection: Regular Data
309

John Doe
35

329 Cobblestone Ln
Edison
NJ
08440
US

View Slide

10. XXE Exploit: Data Exfiltration
310

]>
&xxe;
Data Exfiltration: An attacker can leverage XML entities to disclose internal files. This is the most common use
case for XXE.
In the above code, an attacker tries to read the /etc/passwd file
from a Unix-based system. If the XML processor is configured
improperly and parses this XML, it can end up sending the
contents of that file back to the attacker.
:
This is an element declaration within the DTD. A foo element can
contain any content (i.e., ANY).
]:
This is where things get interesting. It's an entity declaration that
creates an entity named xxe. The SYSTEM keyword means it's an
external entity, and the provided URL (file:///etc/passwd) indicates
where the entity's value/content should be fetched from.
In this case, it's trying to fetch the contents of the /etc/passwd file,
a well-known Unix file containing user account details (though,
importantly, not password hashes in modern systems).
&xxe;
In XML, the use of & followed by a name and a ; is an entity
reference. It tells the XML parser to replace that reference with
the value of the specified entity.
The &xxe; is an entity reference that refers to the xxe entity that
was previously defined in the document's DTD.
This begins the definition of a Document Type
Declaration (DTD) for an XML document. foo is the
name of the root element for documents of this type.

View Slide

10. XXE Exploit: DoS Attack
311

]>
&lol9;

View Slide

10. XXE Exploit: Server-Side Request Forgery (SSRF)
312

]>
&xxe;
An attacker can make the server issue requests to other internal resources,
potentially bypassing firewalls or disclosing internal systems.
This might be used to access an internal admin panel or API that's not normally
accessible from the outside.

View Slide

10. XXE Exploit: Port Scanning
313

]>
&xxe;
Attackers can determine which ports are open on the server or on related servers.

View Slide

10. XXE Exploit: Blind XXE
314

" >]>
&xxe;
This is used to exfiltrate data even when the application doesn't display the output
of the XML parsing. This typically involves making the server reach out to a
malicious domain.
The attacker would look for requests to their domain (attacker.com) to see the
exfiltrated data

View Slide

10. XXE: Vulnerable Code
315

View Slide

10. XXE: Code Fix
316
1. Disable DTD
2. Disable Extern General Entities – Not to process External General Entities
3. Disable External Parameter Entities – They can’t be used within the main XML Content.

View Slide

10. XXE: Code Fix
317
1. Disable DTD
2. Disable Extern General Entities – Not to process External General Entities
3. Disable External Parameter Entities – They can’t be used within the main XML Content.

View Slide

11. XPath Injection
318
XPath Injection is an attack technique that exploits applications that construct
XPath (XML Path Language) queries from user-supplied input to query or navigate
XML documents. XPath Injection attacks are similar to SQL Injection attacks in that
they exploit the same input validation vulnerabilities but exploit the XPath query
language used by XML applications.
• XPath Injection attacks can extract confidential data from an application's database.
XPath Injection can also be used to modify content in the database, which may result in web
defacement or system compromise.
• XPath Injection can bypass authentication or authorization functions or act as a stepping-stone
toward other attacks.
• XPath Injection can execute arbitrary system commands, which may result in total system
compromise.
• XPath Injection can access local or remote files and services through the XML document.

View Slide

11. XPath: How it Works
319
1.User Input in Queries: Like SQL injection, XPath
injection attacks occur when a web application
constructs an XPath query with unsafe user input.
2.Manipulating Query Logic: An attacker can
manipulate the logic of the XPath query, leading to
unintended consequences. This could be gaining
unauthorized access, bypassing authentication, or
retrieving sensitive data.

View Slide

11. XPath: Potential Damages
320
1. Data Theft: An attacker can modify the XPath query to return sensitive data from the XML
source they shouldn't have access to. This could include user, configuration, or any other stored
data.
2. Bypassing Authentication: Some applications may use XML data sources to store user
credentials. An attacker can manipulate XPath queries to bypass authentication. For instance, an
attacker might provide a value that always returns true for a login check.
3. Data Tampering: While XPath is primarily a query language, it can also be used in contexts where
data gets written or updated. An attacker could modify XML data if the system is designed
insecurely.
4. Denial of Service (DoS): By injecting certain types of payload, attackers can create XPath queries
that are highly resource-intensive, leading to denial-of-service attacks.
5. Execution of Malicious Code: In specific scenarios, especially when combined with other
vulnerabilities, an attacker might be able to leverage an XPath Injection vulnerability to execute
malicious code.

View Slide

11. XPath: Counter Measures
321
1. Input Validation: Use a strong type, white-list input validation. Ensure user input
matches the expected format before incorporating it into an XPath query.
2. Use Parameterized Queries: Similar to using prepared statements in SQL, using APIs or
libraries that support parameterized XPath expressions can prevent injection.
3. Least Privilege: Ensure that the XML data source user account used by the web
application has the least privilege necessary.
4. Sanitize Input: If user input is used in an XPath query, ensure that special characters are
properly escaped or removed.
5. Avoid Displaying Errors: Do not display detailed error messages to end users. Attackers
can glean important information from error messages that can help refine their attack.
6. Regularly Update Software: Regularly update all software, especially XML processors,
to protect you from known vulnerabilities.

View Slide

11. XPath: Vulnerable Code
322

View Slide

11. XPath: Code Fix
323

View Slide

11. XPath: Understanding the Fix
324
1. xpath.setXPathVariableResolver(...): This method sets a custom variable resolver to the XPath
object. When the XPath expression is evaluated, and it encounters a variable, this resolver is
called to determine the value of that variable.
2. public Object resolveVariable(QName variableName): This method implements the
XPathVariableResolver interface. It is called when the Xpath engine encounters a variable during
its evaluation.
3. If (“username”.equals(variableName.getLocalPart())): This checks if the encountered variable in
the Xpath expression has the name “username”.
4. Return username;: If the variable’s name is “username”, it returns the value of the username
variable from the enclosing method’s scope.
5. Return null;: If the variable’s name is not “username”, it returns null. In a more complex system,
you might have multiple checks for different variable names.
6. Using the XPathVariableResolver, you can dynamically set the values of variables in your XPath
expression from your Java code. This can be especially useful for preventing XPath Injection, as
you can safely bind values without concatenating strings.

View Slide

11. Cross-Site Request Forgery (CSRF)
325
Cross-Site Request Forgery (CSRF) is a web security vulnerability that tricks the
victim into performing an unintended action in an application where they're
currently authenticated. This can result in unwanted state changes, like changing an
authenticated user’s email address or password or even performing financial
transactions.
How CSRF attack works:
1. The attacker tricks the victim into clicking a link or loading an image.
2. The victim's browser sends a request to the targeted web application where the
victim is already authenticated, often including any cookies or authentication
tokens automatically.
3. The web application cannot distinguish this legitimate-looking request from one
the authenticated user might make.

View Slide

11. Microservices
326
Stateless Microservices and JWT:
Microservices are often designed to be stateless for
scalability reasons. This means they don't retain client-
specific data between requests; each request contains
all the information the microservice needs to process it.
JSON Web Tokens (JWT) are a compact way to
represent claims between two parties and are often
used in stateless microservices architectures for
authentication and authorization.

View Slide

11. CSRF & Microservices
327
Are Stateless Microservices with JWT immune to CSRF?
JWT tokens provide some inherent protection against CSRF, especially when not using cookies to
store JWT. Here's why:
1. No Automatic Token Transmission: Unlike cookies, browsers automatically attach to every
request to a domain. JWTs stored in local storage or session storage aren't automatically
included in every request to a domain. The application has to attach the JWT to the request
header explicitly. This means an attacker can’t simply trick a victim’s browser into making an
authenticated request with a JWT, as they can with cookies.
2. Same Origin Policy: Storing JWT in local storage or session storage means it’s subject to the
same-origin policy. An attacker’s website cannot read or modify the JWT stored locally on
another domain.
However, if a microservice or application stores the JWT inside a cookie (a practice some
applications might adopt for easier handling of the JWT on the client side), CSRF becomes a
potential concern. Even if the microservice is stateless, cookies can make it vulnerable.

View Slide

11. CSRF: Counter Measures
328
1. Don't Store JWT in Cookies: The most straightforward way to prevent CSRF in a
JWT-based system is to store the JWT in local storage or session storage, not in
cookies.
2. CSRF Tokens: If, for some reason, you must store JWT or session identifiers in
cookies, use anti-CSRF tokens. This random token is included as a hidden field in
every form submitted to the server. Before processing the form, the server
checks that the token is present and correct. Since the attacker can't predict this
token, they can't craft a valid form submission.
3. SameSite Cookie Attribute: Modern browsers support the SameSite attribute on
cookies, which can prevent the browser from sending the cookie in cross-site
requests. This is another layer of protection against CSRF.
4. Check the Origin Header: For requests that may change state (POST, PUT,
DELETE), check the Origin header to ensure the request comes from your front-
end application and not a third-party site.

View Slide

11. CSRF: Code Fix
329
A new CSRF token is
created and saved
in the session, it will
also be added as a
response header
named
X-CSRF-TOKEN

View Slide

11. CSRF: Code Fix
330
Configure Spring Security by Extending the WebSecurityConfigurerAdapter
o How this leads to another problem when you want Horizontal Scalability!
o What are the possible solutions?

View Slide

11. CSRF – Horizontal Scalability
331
1. How Sessions Typically Work with Multiple Instances:
When you run multiple server instances behind a load balancer, you must ensure that session
data is shared between all instances, so any instance can handle a request, regardless of
which instance created the session. This can be achieved using a shared session store.
2. Using Redis for Session Management:
Redis is famous for distributed session management in such scenarios because of its high-
speed in-memory data structure storage capabilities.
3. Redis to store sessions (and CSRF tokens within those sessions):
1. Instead of storing session data in the local application server’s memory, you store it in
Redis.
2. Each application instance connects to the same Redis instance (or cluster) and retrieves or
sets session data from/to Redis.
3. When a user’s request comes into any application instance, that instance checks Redis for
the session data, ensuring continuity across requests even if different servers handle
them.

View Slide

11. CSRF: Redis Storage
332
1. Storing CSRF Tokens in Redis:
By moving to a Redis-based session management, CSRF tokens (part of the session data) will also be
stored in Redis. This ensures that even if a user's subsequent request (with the CSRF token) goes to a
different application instance than the one that generated the token, the token will still be validated
correctly, as all instances are looking at the same session store in Redis.
2. Setting Up Redis Session Management in Spring Boot:
Spring Boot makes it relatively easy to set up Redis-based session management:
1. Add the required dependencies to your pom.xml:

org.springframework.boot
spring-boot-starter-data-redis

org.springframework.session
spring-session-data-redis

View Slide

11. CSRF: Redis Storage
333
1. Configure your App
1. Configure the connection to your Redis instance in application.properties or
application.yml.
2. Annotate your main Spring Boot application class with
@EnableRedisHttpSession.
2. This will configure your Spring Boot app to use Redis for session management.
CSRF tokens, being part of the session, will also be stored in Redis.
3. Redis provides a centralized session store that addresses the session distribution
problem and introduces a single point of failure.
4. Consider using Redis in a clustered mode or ensure adequate failover
mechanisms are in place.

View Slide

11. CSRF: Code Fix
334
Suppose you want CSRF validation specifically for a particular GET
request while maintaining CSRF validation for standard state-changing
operations (like POST requests). In that case, you can customize the
requireCsrfProtectionMatcher method to include that specific GET
endpoint.

View Slide

11. CSRF: Code Fix
335
1. Request Path Matching: If the request
path matches /path and the HTTP
method is GET (as per your custom
matcher), the CSRF check will be
triggered.
2. Token Check: Spring Security will look
for the CSRF token in the request. By
default, it checks for the token in the
request parameters with the
parameter name _csrf. Spring Security
will look for it if you’ve customized the
location, like setting it in the header (a
common approach with AJAX
requests).
3. Token Absence or Mismatch: If the
token is absent or doesn't match the
token on the server, Spring Security
will throw a CsrfException. The user
will typically receive a 403 Forbidden
response.

View Slide

12. Server-Side Request Forgery (SSRF)
336
SSRF is a vulnerability that allows an attacker to trigger the
server to make unintended requests to other servers, often
bypassing firewall restrictions and accessing services from the
server's local network. This can lead to sensitive information
disclosure, internal network enumeration, or even remote
code execution.
For example, imagine a web application that fetches the
content of a URL provided by the user. An attacker could
abuse this to make the server retrieve the content of an
internal, potentially sensitive URL, like AWS metadata, which
can contain sensitive information.

View Slide

12. SSRF: Counter Measures
337
1. Whitelisting URLs: Only allow connections to known, safe URLs.
2. Disallow Private IP Ranges: Block requests to private IP ranges to
prevent access to internal network resources.
3. Limit HTTP Methods: Only allow safe HTTP methods (e.g., GET) if
necessary.
4. Use a Proxy: Force all outbound requests to go through a proxy.
5. Timeouts: Implement reasonable timeouts for outbound requests
to avoid long-lasting connections that can be used for DoS.
6. Monitoring and Logging: Log all outbound requests to detect and
respond to potential SSRF attempts.

View Slide

12. SSRF: Vulnerable Code
338

View Slide

12. SSRF: Code Fix
339
Fix:
1. Use a list of allowed hosts or
domains.
2. Block private IP addresses.
3. Implement a timeout for the
request.

View Slide

Spring Security
o Security Features
o Cross-Site Request Forgery
o Handling iFrames
o Cross-Site Scripting
o Mime Attacks
o Content Security Policy
340

View Slide

Spring Security – 1 of 3
341
1. Flexible Authentication Mechanisms: Spring Security provides multiple authentication
mechanisms, but the stateless JWT (JSON Web Tokens) authentication becomes critical for
microservices.
2. Stateless Authentication: Since microservices aim to be stateless for scalability, using JWTs
ensures there's no session state stored on the server between requests. Every request comes
with a token that the server verifies.
3. Declarative Security on Methods and URLs: You can secure methods or REST endpoints using
annotations such as @PreAuthorize or @Secured. This makes it easy to define role-based access
controls at the granularity of specific operations or endpoints.
4. OAuth2 Integration: With Spring Security, you can set up your microservices as OAuth2 clients,
or even as an authorization server. OAuth2 and JWT often go hand in hand in microservice
architectures.
5. Filter Chain: Spring Security works by applying a series of filters to incoming requests. This is
particularly useful for JWT as a custom JWT processing filter can be inserted into this chain to
handle JWT extraction and validation.

View Slide

342
6. Exception Handling: Proper authentication and authorization exception handling
mechanisms can be integrated, ensuring that unauthorized or unauthenticated
requests receive proper HTTP error codes and messages.
7. Integration with Spring Cloud: When combined with Spring Cloud, additional security
features can be employed, such as gateway-based authentication and secure service-
to-service communication.
8. Cross-Site Request Forgery (CSRF) Protection: For services that might be accessed
from web browsers, Spring Security offers CSRF protection out-of-the-box.
9. CORS Configuration: Spring Security provides a way to set up Cross-Origin Resource
Sharing (CORS) configurations to control and secure the access of microservices from
different origins.
10. Security Events and Sessions: Spring Security fires events on various activities, such as
login success or failure, which can be captured for monitoring or logging purposes.

View Slide

343
11. Method Security: Beyond URL-based security, Spring Security can secure
method calls based on the role, authentication, or other conditions.
12. Password Encoding: Spring Security offers a plethora of password encoding and
decoding mechanisms, critical for securely storing and verifying user passwords.
13. SSL/TLS Configuration: Ensuring encrypted communication between services,
Spring Security aids in establishing and enforcing SSL/TLS.
14. Content Negotiation: Since microservices often expose RESTful APIs that serve
different types of content (like JSON or XML), Spring Security plays well with
Spring's content negotiation features.
15. Actuator Security: If Spring Boot’s actuator endpoints are used to monitor and
manage microservices, it can secure them, ensuring that only authorized
personnel can access them.

View Slide

Spring Security: Authorization
344

View Slide

Spring Security: CSRF
345
Cross-Site Request Forgery
This line configures the Cross-Site Request Forgery (CSRF) protection using a header-based CSRF
token repository. This is the recommended approach for CSRF protection. It will cause the server to
generate a CSRF token and set it as a header named X-CSRF-TOKEN. The client must then read the
token from the header and send it as a request header named X-CSRF-TOKEN with each request. The
server will then validate the token to ensure the request is not a CSRF attack.

View Slide

Spring Security: iFrames
346
X-Frame-Options
X-Frame-Options is a security header to protect your website against "click-jacking"
attacks. Click-jacking is a malicious technique of tricking web users into revealing
confidential information or taking control of their interaction with the website by
loading your website in an iframe of another website and then overlaying it with
additional content.

View Slide

Spring Security: XSS
347
1. xssProtection(): This method configures the X-XSS-Protection HTTP header.
Microsoft introduced the X-XSS-Protection header in Internet Explorer 8 as a way
to enable the browser's built-in Cross-Site Scripting (XSS) filter.
2. block(true): The block(true) method configures the X-XSS-Protection header to
have a value of 1; mode=block. When this value is set, the browser will not only
detect potential XSS attacks but also prevent the rendering of the page if an
attack is detected (i.e., it will "block" the page).
3. Not all modern browsers respect the X-XSS-Protection header, with some
deprecating it in favor of the more robust Content-Security-Policy header.

View Slide

Spring Security: Mime Attacks
348
MIME-type Confusion Attack
Web servers send a Content-Type header to inform the browser about the type of
data being sent (e.g., text/html, text/css, application/javascript). Browsers, in an
attempt to be helpful, sometimes perform MIME sniffing. This means that if a
browser receives a resource and suspects the Content-Type might be incorrect, it
tries to guess the right one.
By using the X-Content-Type-Options: nosniff header, the server tells the browser
not to perform MIME-type sniffing, i.e., to trust the provided Content-Type header
and not guess or change the MIME type.

View Slide

Spring Security: Content Security Policy
349
The Content Security Policy (CSP) is a security feature implemented in web browsers. Its primary
goal is to mitigate the risk of cross-site scripting (XSS) and other code injection attacks. By defining a
set of rules for how resources on a web page can be loaded, CSP helps prevent unauthorized script
execution and resource loading.
In the context of Spring, and more specifically Spring Security, there are provisions to easily set the
CSP header in HTTP responses to guide browsers on what resources are allowed or disallowed.

View Slide

CSP: How it works
350
CSP works by defining a set of directives as a policy. This policy is sent
to the browser as an HTTP header named Content-Security-Policy.
These directives tell the browser where resources can be loaded from,
which scripts are allowed to execute, which styles can be applied, etc.
1. By default (default-src), only allow resources from the same origin.
2. Allow scripts (script-src) to be loaded from the same origin and
hostname.
3. Allow images (img-src) to be loaded from the same origin and img.
hostname.
4. Allow styles (style-src) only from the same origin.

View Slide

CSP: Benefits and Drawbacks
351
Benefits:
1. Mitigating XSS: Since CSP can control which scripts can run, it offers a robust defense
against XSS attacks.
2. Control over resources: You can specify from where various types of resources (scripts,
styles, images, fonts, etc.) can be loaded.
3. Inline script control: You can control the execution of inline scripts, which are often
used in XSS attacks.
4. Plugin control: You can control which plugins can run and from where they can be
loaded.
Drawbacks:
1. Complexity: CSP can be complex and might require careful tuning to not break
legitimate functionalities of the application.
2. Legacy browser support: Not all browsers, especially older versions, support CSP.

View Slide

Spring Security
352

View Slide

DREAM | AUTOMATE | EMPOWER
Araf Karsh Hamid :
India: +91.999.545.8627
https://github.com/arafkarsh
https://speakerdeck.com/arafkarsh
http://www.slideshare.net/arafkarsh
https://www.linkedin.com/in/arafkarsh/
https://www.youtube.com/user/arafkarsh/playlists
http://www.arafkarsh.com/
@arafkarsh
arafkarsh

View Slide

354
Source: https://github.com/arafkarsh Security Repo: https://github.com/arafkarsh/ms-springboot-272-vanilla

View Slide

http://www.slideshare.net/arafkarsh
Source: https://speakerdeck.com/arafkarsh

View Slide

Design Patterns are
solutions to general
problems that
software developers
faced during software
development.
Design Patterns

View Slide

Java Application Security

Java Application Security

Araf Karsh Hamid

More Decks by Araf Karsh Hamid

Other Decks in Technology

Featured

Transcript