UNIT II SECURE DEVELOPMENT AND

DEPLOYMENT
Web Applications Security:
Securing web applications is a critical aspect of software development and
deployment. The goal is to protect the application and its users from various security
threats and vulnerabilities. Here are key practices for secure development and
deployment of web applications:

Secure Development Practices:

1. Input Validation:
 Validate and sanitize all user inputs to prevent injection attacks (e.g.,
SQL injection, cross-site scripting).
 Use parameterized queries to prevent SQL injection.
2. Authentication and Authorization:
 Implement strong authentication mechanisms, including multi-factor
authentication when possible.
 Follow the principle of least privilege for user permissions.
 Regularly review and update access controls.
3. Session Management:
 Use secure and random session IDs.
 Implement session timeout and reauthentication for sensitive actions.
 Store session data securely, preferably on the server side.
4. Cross-Site Request Forgery (CSRF) Protection:
 Include anti-CSRF tokens in forms.
 Ensure that state-changing requests require proper authentication.
5. Cross-Origin Resource Sharing (CORS):
 Implement proper CORS policies to control which domains can access
resources.
 Avoid overly permissive CORS configurations.
6. Security Headers:
 Utilize security headers like Content Security Policy (CSP), Strict-
Transport-Security (HSTS), and X-Content-Type-Options.
7. File Upload Security:
 Validate file types and enforce size limits.
 Store uploaded files in a secure location outside the web root.
8. Error Handling:
 Provide custom error pages to avoid leaking sensitive information.
 Log errors securely without exposing sensitive data.
9. Code Reviews and Static Analysis:
  Regularly conduct code reviews to identify security vulnerabilities.
 Use static analysis tools to scan code for potential security issues.
10. Dependency Management:
 Keep all dependencies up-to-date to patch known vulnerabilities.
 Use a secure package manager and regularly audit dependencies.

Secure Deployment Practices:

1. Web Application Firewall (WAF):

 Deploy a WAF to filter and monitor HTTP traffic between a web
application and the Internet.
 Configure the WAF to protect against common web application attacks.
2. HTTPS:
 Enforce the use of HTTPS to encrypt data in transit.
 Use strong, up-to-date encryption protocols and ciphers.
3. Secure Configuration:
 Disable unnecessary services and features.
 Follow security best practices for server and database configurations.
4. Continuous Monitoring:
 Implement monitoring solutions to detect and respond to security
incidents.
 Regularly review logs for suspicious activities.
5. Incident Response Plan:
 Develop and document an incident response plan.
 Test the plan regularly to ensure a swift and effective response.
6. Data Backups:
 Regularly backup data and ensure the backups are secure.
 Test data restoration procedures to guarantee recoverability.
7. Environment Isolation:
 Isolate production, development, and testing environments.
 Limit access to production systems to only authorized personnel.
8. Regular Security Audits:
 Conduct regular security audits and penetration testing.
 Address and remediate any vulnerabilities discovered during audits.
9. Security Training:
 Provide security awareness training for development and operations
teams.
 Keep teams informed about the latest security threats and best
practices.
10. Compliance:
 Ensure compliance with relevant security standards and regulations
(e.g., GDPR, HIPAA).
By incorporating these practices into the development and deployment processes,
you can significantly enhance the security posture of your web applications.
Regularly updating and adapting security measures to address emerging threats is
also crucial for ongoing protection.

Security Testing, Security Incident Response Planning

Security testing and incident response planning are essential components of a
comprehensive cybersecurity strategy. Here's an overview of each:

Security Testing:

1. Penetration Testing:
 Purpose: To identify vulnerabilities and weaknesses in the application
or network.
 Method: Ethical hackers simulate real-world attacks to uncover security
issues.
 Frequency: Conduct regular penetration tests, especially after major
updates or changes.
2. Vulnerability Scanning:
 Purpose: Automated tools scan systems for known vulnerabilities.
 Method: Regularly scan networks, applications, and systems for known
security issues.
 Frequency: Implement continuous scanning to detect and address
vulnerabilities promptly.
3. Code Review:
 Purpose: Identifying security vulnerabilities in the source code.
 Method: Manual or automated review of the application's source code.
 Frequency: Regularly integrate code reviews into the development
process.
4. Security Audits:
 Purpose: Comprehensive review of security policies, configurations,
and practices.
 Method: Evaluate all aspects of security, including physical security,
policies, and procedures.
 Frequency: Conduct periodic security audits to ensure ongoing
compliance and effectiveness.
5. Security Automation:
 Purpose: Automating security tests and checks.
 Method: Use tools for automated security testing, such as static
analysis tools, dynamic analysis tools, and security scanning tools.
  Frequency: Integrate automation into the development and testing
pipeline.
6. Compliance Testing:
 Purpose: Ensure compliance with relevant security standards and
regulations.
 Method: Evaluate the system against specific compliance
requirements.
 Frequency: Regularly assess and update compliance measures.

Security Incident Response Planning:

1. Incident Response Team:

 Formation: Establish a dedicated incident response team.
 Roles: Define roles and responsibilities for team members.
 Training: Ensure the team is trained and regularly updated on incident
response procedures.
2. Incident Identification:
 Detection Systems: Implement systems to detect and alert on security
incidents.
 Monitoring: Continuously monitor logs and network traffic for
anomalies.
 User Reporting: Encourage users to report suspicious activities
promptly.
3. Incident Classification and Triage:
 Classification: Define incident severity levels.
 Triage: Develop a process for quickly assessing and categorizing
incidents.
4. Incident Containment:
 Isolation: Quickly isolate affected systems to prevent further damage.
 Communication: Establish clear communication channels within the
response team and with relevant stakeholders.
5. Eradication and Recovery:
 Root Cause Analysis: Identify and eliminate the root cause of the
incident.
 System Restoration: Restore affected systems from clean backups.
 Validation: Verify that the systems are free from compromise.
6. Communication and Notification:
 Internal Communication: Keep the internal team and relevant
stakeholders informed.
 External Communication: Develop a communication plan for
notifying external parties, such as customers, regulatory bodies, and
law enforcement if necessary.
 7. Post-Incident Analysis:
 Debriefing: Conduct a thorough post-incident analysis.
 Documentation: Document lessons learned and update incident
response plans accordingly.
 Continuous Improvement: Use the insights gained to enhance
incident response capabilities.
8. Legal and Regulatory Compliance:
 Reporting: Comply with legal and regulatory requirements for
reporting incidents.
 Documentation: Maintain documentation to demonstrate compliance
efforts.
9. Training and Exercises:
 Regular Drills: Conduct simulated incident response drills.
 Training Programs: Ensure ongoing training for the incident response
team and relevant staff.
10. Documentation and Record-Keeping:
 Incident Logs: Keep detailed logs of incident response activities.
 Post-Incident Report: Produce a comprehensive post-incident report
for internal and external review.

By implementing a robust security testing program and having a well-defined

incident response plan, organizations can proactively identify and mitigate security
risks, respond effectively to incidents, and continuously improve their overall security
posture. Regular testing, training, and updates to incident response plans are crucial
to staying ahead of evolving cybersecurity threats.
The Microsoft Security Development Lifecycle (SDL)
Microsoft Security Development Lifecycle (SDL)
 Article
 03/03/2023
 2 contributors
Feedback

In this article
1. Training
2. Requirements
3. Design
4. Implementation
Show 3 more

Security and privacy should never be an afterthought when developing secure

software, a formal process must be in place to ensure they're considered at all points
of the product's lifecycle. Microsoft's Security Development Lifecycle (SDL) embeds
comprehensive security requirements, technology specific tooling, and mandatory
processes into the development and operation of all software products. All
development teams at Microsoft must adhere to the SDL processes and
requirements, resulting in more secure software with fewer and less severe
vulnerabilities at a reduced development cost.

Microsoft SDL consists of seven components including five core phases and two
supporting security activities. The five core phases are requirements, design,
implementation, verification, and release. Each of these phases contains mandatory
checks and approvals to ensure all security and privacy requirements and best
practices are properly addressed. The two supporting security activities, training and
response, are conducted before and after the core phases respectively to ensure
they're properly implemented, and software remains secure after deployment.

Training

All Microsoft employees are required to complete general security awareness

training and specific training appropriate to their role. Initial security awareness
training is provided to new employees upon hire and annual refresher training is
required throughout their employment at Microsoft.

Developers and engineers must also participate in role specific training to keep them
informed on security basics and recent trends in secure development. All full-time
employees, interns, contingent staff, subcontractors, and third parties are also
encouraged and provided with the opportunity to seek advanced security and
privacy training.
Requirements

Every product, service, and feature Microsoft develops starts with clearly defined
security and privacy requirements; they're the foundation of secure applications and
inform their design. Development teams define these requirements based on factors
such as the type of data the product will handle, known threats, best practices,
regulations and industry requirements, and lessons learned from previous incidents.
Once defined, the requirements are clearly defined, documented, and tracked.

Software development is a continuous process, meaning that the associated security

and privacy requirements change throughout the product's lifecycle to reflect
changes in functionality and the threat landscape.

Design

Once the security, privacy, and functional requirements have been defined, the
design of the software can begin. As a part of the design process, threat models are
created to help identify, categorize, and rate potential threats according to risk.
Threat models must be maintained and updated throughout the lifecycle of each
product as changes are made to the software.
The threat modeling process begins by defining the different components of a
product and how they interact with each other in key functional scenarios, such as
authentication. Data Flow Diagrams (DFDs) are created to visually represent key data
flow interactions, data types, ports, and protocols used. DFDs are used to identify
and prioritize threats for mitigation that are added to the product's security
requirements.

Developers are required to use Microsoft's Threat Modeling Tool for all threat
models, which enables the team to:

 Communicate about the security design of their systems

 Analyze security designs for potential security issues using a proven
methodology
 Suggest and manage mitigation for security issues

Before any product is released, all threat models are reviewed for accuracy and
completeness, including mitigation for unacceptable risks.
Implementation

Implementation begins with developers writing code according to the plan they
created in the previous two phases. Microsoft provides developers with a suite of
secure development tools to effectively implement all the security, privacy, and
function requirements of the software they design. These tools include compilers,
secure development environments, and built-in security checks.

Verification

Before any written code can be released, several checks and approvals are required
to verify that the code conforms to SDL, meets design requirements, and is free of
coding errors. SDL requires that manual reviews are conducted by a reviewer
separate from the personnel the developed the code. Separation of duties is an
important control in this step to ensure no code can be written and released by the
same person leading to potential accidental or malicious harm.

Various automated checks are also required and are built into the commit pipeline to
analyze code during check-in and when builds are compiled. The security checks
used at Microsoft fall into the following categories:

 Static code analysis: Analyzes source code for potential security flaws,
including the presence of credentials in code.
 Binary analysis: Assesses vulnerabilities at the binary code level to confirm
code is production ready.
 Credential and secret scanner: Identify possible instances of credential and
secret exposure in source code and configuration files.
 Encryption scanning: Validates encryption best practices in source code and
code execution.
 Fuzz testing: Use malformed and unexpected data to exercise APIs and parsers
to check for vulnerabilities and validate error handling.
 Configuration validation: Analyzes the configuration of production systems
against security standards and best practices.
 Component Governance (CG): Open-source software detection and checking
of version, vulnerability, and legal obligations.

If the manual reviewer or automated tools find any issues in the code, the submitter
will be notified, and they're required to make the necessary changes before
submitting it for review again.

Additionally, penetration tests are regularly conducted on Microsoft online services

by both internal and external providers. Penetration tests provide another means for
discovering security flaws not detected by other methods. To learn more about
penetration testing at Microsoft, see Attack simulation in Microsoft 365.
Release

After passing all required security tests and reviews, builds aren't immediately
released to all customers. Builds are systematically and gradually released to larger
and larger groups, referred to as rings, in what is called a safe deployment process
(SDP). The SDP rings are defined as follows:

 Ring 0: The development team responsible for the service

 Ring 1: All Microsoft employees
 Ring 2: Users outside of Microsoft who have configured their organization or
specific users to be on the targeted release channel
 Ring 3: Worldwide standard release in sub-phases

Builds remain in each of these rings for an appropriate number of days with high
load periods, except for Ring 3 since the build has been appropriately tested for
stability in the earlier rings.

OWASP Comprehensive Lightweight Application Security

Process (CLASP)
Concepts View
CLASP — Comprehensive, Lightweight Application Security Process —
is an activitydriven, role-based set of process components whose
core contains formalized best practices for building security into your
existing or new-start software development lifecycles in a structured,
repeatable, and measurable way.
CLASP is the outgrowth of years of extensive field work in which
system resources of many development lifecycles were methodically
decomposed in order to create a comprehensive set of security
requirements. These resulting requirements form the basis of
CLASP’s best practices which allow organizations to systematically
address vulnerabilities that, if exploited, can result in the failure of
basic security services — e.g., confidentiality, authentication, and
access control.
• Adaptability of CLASP to Existing Development Processes
CLASP is designed to allow you to easily integrate its security-related
activities into your existing application development processes. Each
CLASP activity is divided into discrete process components and linked
to one or more specific project roles. In this way, CLASP provides
guidance to project participants — e.g., project managers, security
auditors, developers, architects, testers, and others — that is easy to
adopt to their way of working; this results in incremental
improvements to security that are easily achievable, repeatable, and
measurable.
• CLASP Vulnerability Lexicon
CLASP also contains a comprehensive Vulnerability Lexicon that
helps development teams avoid/remediate specific designing/coding
errors that can lead to exploitable security services. The basis of this
Lexicon is a highly flexible taxonomy — i.e., classification structure —
that enables development teams to quickly locate Lexicon
information from many perspectives: e.g., problem types (i.e., basic
causes of vulnerabilities); categories of problem types; exposure
periods; avoidance and mitigation periods; consequences of
exploited vulnerabilities; affected platforms and programming
languages; risk assessment.
• Automated Analysis Tools
Much of the information in the CLASP Vulnerability Lexicon can be
enforced through use of automated tools using techniques of static
analysis of source code.
Overview of CLASP Process
This section provides an overview of CLASP’s structure and of the
dependencies between the CLASP process components and is
organized as follows:
• CLASP Views
• CLASP Resources
• Vulnerability Use Cases
CLASP Views
The CLASP process is presented through five high-level perspectives
called CLASP Views. These views are broken down into activities
which in turn contain process components. This top-down
organization by View > Activity > Process Component allows you to
quickly understand the CLASP process, how CLASP pieces interact,
and how to apply them to your specific software development
lifecycle.
These are the CLASP Views:
• Concepts View
• Role-Based View
• Activity-Assessment View
• Activity-Implementation View
• Vulnerability View
The following figure shows the CLASP Views and their interactions:
CLASP Resources
The CLASP process supports planning, implementing and performing
security-related software development activities. The CLASP
Resources provide access to artifacts that are especially useful if your
project is using tools to help automate CLASP process pieces
. This table lists the name and location of CLASP Resources delivered
with CLASP and indicates which CLASP Views they can support:
CLASP Resources Location
• Basic Principles in Application Security (all Views) Resource A
• Example of Basic Principle: Input Validation (all Views) Resource B
• Example of Basic-Principle Violation: Penetrate-and-Patch Model
(all Views) Resource C
• Core Security Services (all Views; especially III) Resource D
• Sample Coding Guideline Worksheets (Views II, III & IV) Note: Each
worksheet can be pasted into a MS Word document. Resource E
• System Assessment Worksheets (Views III & IV) Note: Each
worksheet can be pasted into a MS Word document. Resource F •
Sample Road Map: Legacy Projects (View III) Resource G1 • Sample
Road Map: New-Start Projects (View III) Resource G2 • Creating the
Process Engineering Plan (View III) Resource H • Forming the Process
Engineering Team (View III) Resource I • Glossary of Security Terms
(all Views) Resource J Version Date: 31 March 2006 5 CLASP Concepts
View — Overview of CLASP Process
Vulnerability Use Cases
The CLASP Vulnerability Use Cases depict conditions under which
security services can become vulnerable in software applications. The
Use Cases provide CLASP users with easy-to-understand, specific
examples of the cause-and-effect relationship between security-
unaware design/source coding and possible resulting vulnerabilities
in basic security services — e.g., authentication authorization,
confidentiality, availability, accountability, and non-repudiation.
The CLASP Vulnerability Use Cases are based on the following
common component architectures:
• Monolithic UNIX
• Monolithic mainframe
• Distributed architecture (HTTP[S] & TCP/IP)
It is recommended to understand the CLASP Use Cases as a bridge
from the Concepts View of CLASP to the Vulnerability Lexicon (in the
Vulnerability View) since they provide specific examples of security
services becoming vulnerable in software applications
CLASP Best Practices
 If security vulnerabilities built into your applications’ source code
survive into production, they can become corporate liabilities with
broad and severe business impact on your organization. In view of
the consequences of exploited security vulnerabilities, there is no
reasonable alternative to using best practices of application security
as early as possible in — and throughout — your software
development lifecycle.

The Software Assurance Maturity Model (SAMM)

Software Assurance Maturity Model

Our mission is to provide an effective and measurable way for you to analyze and
improve your secure development lifecycle. SAMM supports the complete
software lifecycle and is technology and process agnostic. We built SAMM to
be evolutive and risk-driven in nature, as there is no single recipe that works for
all organizations.
Check out the OWASP SAMM v2 model online:

Get OWASP SAMM new delivered to your mailbox

 Subscribe to our newsletter

Join us on the OWASP SAMM project Slack channel

 Join our project slack channel

 Invitations (self registration) via: https://owasp.org/slack/invite

Join our monthly calls

 The monthly call is on each 2nd Wednesday of the month at 21h30 CET /
3:30pm ET.
 Register through our SAMM MeetUp to join the Zoom call.
 The call is open for everybody interested in SAMM or who wants to work
on SAMM.

The Software Assurance Maturity Model (SAMM) is an open framework to help

organizations formulate and implement a strategy for software security that is
tailored to the specific risks facing the organization. SAMM helps you:

 Evaluate an organization’s existing software security practices

 Build a balanced software security assurance program in well-defined
iterations
 Demonstrate concrete improvements to a security assurance program
 Define and measure security-related activities throughout an
organization
Dell uses OWASP’s Software Assurance Maturity Model (Owasp SAMM) to
help focus our resources and determine which components of our secure
application development program to prioritize., (Michael J. Craigue,
Information Security & Compliance, Dell, Inc.)

As of my last knowledge update in January 2022, the Software Assurance Maturity Model
(SAMM) is an open framework maintained by the Open Web Application Security Project
(OWASP). SAMM provides an effective and measurable way for all types of organizations to
analyze and improve their software security posture.

Key Components of SAMM:

1. Governance:
 Objective: Establish and maintain the appropriate level of software security
governance.
 Activities: Define and implement policies, roles, responsibilities, and processes to
support software security.
2. Construction:
 Objective: Ensure that security activities are integrated into the software
development process.
 Activities: Apply security practices during the development phase, including
requirements, design, coding, and testing.
3. Verification:
 Objective: Implement security practices to confirm that software is secure and
meets requirements.
 Activities: Conduct security testing, code review, and use automated tools to
verify the security of the software.
4. Deployment:
 Objective: Develop and implement strategies to deploy software securely.
 Activities: Ensure secure configuration, perform secure deployment, and monitor
security during deployment.
5. Operations:
 Objective: Manage and respond to software security issues in deployed software.
 Activities: Establish incident response and management processes, conduct
regular security operations, and monitor for security incidents.
6. Continuous Improvement:
 Objective: Continuously improve the software security process.
 Activities: Collect and analyze metrics, conduct retrospectives, and refine security
practices based on lessons learned.

SAMM Levels:

SAMM defines three maturity levels for each of the six domains mentioned above:

1. Level 1 - Initial:
 Description: The organization has started considering software security.
  Characteristics: Reactive, ad-hoc practices, and minimal security measures.
2. Level 2 - Defined:
 Description: Security activities are defined and documented.
 Characteristics: Basic processes in place, some level of consistency.
3. Level 3 - Consistent:
 Description: Security practices are consistently applied across the organization.
 Characteristics: Well-defined and consistent processes, proactive measures.
4. Level 4 - Managed:
Description: The organization actively manages and measures its security
practices.
 Characteristics: Metrics-driven, continuous improvement, proactive security
measures.
5. Level 5 - Optimizing:
 Description: Continuous optimization and improvement of security practices.
 Characteristics: Continuous feedback loops, adaptive and innovative security
measures.

SAMM Implementation:

Organizations can use SAMM to assess their current state and define a roadmap for improving
their software security practices. The model provides guidance on activities and practices at each
maturity level, allowing organizations to incrementally enhance their software security posture.

Benefits:

 Measurable Improvement: SAMM allows organizations to measure their maturity and

progress in software security over time.
 Customizable Approach: SAMM is flexible and can be adapted to suit the specific needs
and context of different organizations.
 Comprehensive Framework: SAMM covers various aspects of the software development
lifecycle, providing a holistic approach to software security.
 Community Support: Being an OWASP project, SAMM benefits from community
collaboration and contributions.

For the most recent and detailed information on SAMM, please check the OWASP website or
other authoritative sources. The field of software security evolves, and updates or changes may
have occurred since my last knowledge update.