UNIT-II

SECURE DEVELOPMENT AND DEPLOYMENT

Web Applications Security - Security Testing, Security Incident Response Planning, The Microsoft
Security Development Lifecycle (SDL), OWASP Comprehensive Lightweight Application Security
Process (CLASP), The Software Assurance Maturity Model (SAMM)

Web Applications Security-Security Testing

 Web application security testing is a process of identifying, preventing, and mitigating
security vulnerabilities in web applications. It involves assessing the security of web
applications by examining their code, architecture, and deployment environment.
 Web application security testing can be conducted manually or using automated tools to
identify potential security risks such as cross-site scripting (XSS), SQL injection, buffer
overflow, and malicious file execution.

Need for Web Application Security Testing

 Web application security testing is an important part of any organization’s overall

security strategy. As more and more businesses move to the cloud, they must have a
secure web application to protect their data and ensure compliance with industry
regulations.
 Web applications can be vulnerable to malicious attacks, so organizations need to test
them regularly and take steps to protect them from potential threats.
 The need for web application security testing arises from the fact that web applications
are exposed to public networks and can be accessed by anyone with an internet
connection.
 This means that attackers can easily exploit vulnerabilities in these applications and
gain access to sensitive information or disrupt operations. Additionally, web
applications are often used as entry points into other systems, such as databases or
servers, which can lead to further damage if not properly secured. We have discussed
the importance of web application security testing in our comprehensive security testing
guide.
Business Benefits of Web App Security Testing

Improved Security:

Web application security testing helps identify existing and potential vulnerabilities in the
system, allowing businesses to take proactive steps to mitigate risks. This can reduce the
likelihood of costly data breaches and other malicious attacks.

Enhanced Reputation:

Customers trust businesses that prioritize security, so by testing web applications regularly,
businesses can demonstrate their commitment to protecting customers’ data and maintaining a
positive reputation.

Cost Savings:

By detecting potential problems early on, businesses can save money by avoiding expensive
repairs or replacements due to malicious attacks or data breaches. Additionally, web
application security testing helps organizations comply with industry regulations, which could
result in significant fines in the case of non-compliance.

Improved Performance:

Regularly testing web applications can help identify areas where performance is lagging, or
inefficient processes exist that are causing delays or errors. This allows businesses to make
necessary changes that improve overall performance and user experience.
Increased Efficiency:

By identifying any weak points in the system, web application security testing helps businesses
streamline processes and increase efficiency across the organization by eliminating
unnecessary steps or redundant tasks.

Different Software Testing Types for Web Application Security Testing

Static Application Security Testing (SAST):

This testing type is White Box Testing, which enables developers to identify security
vulnerabilities in the source code of an application during the early stages of the software
development life cycle. Through this method, it can be ensured that the application adheres to
coding guidelines and standards.

Dynamic Application Security Testing (DAST):

This technique involves injecting malicious data into the software to simulate SQL injection
and XSS attacks, with the goal of uncovering common security vulnerabilities. It is a black box
or grey box security testing method which enables testers to identify potential weaknesses in
web applications.

Interactive Application Security Testing (IAST):

It is a combination of both the SAST and DAST technique wherein an IAST agent is placed
within an application that performs the analysis of the app in real-time. A large pool of
Certified Ethical Hackers (CEHs) with years of expertise in delivering security testing services
vulnerabilities to clients across domains.
Vulnerability Scanning:

In this testing process, automated software is utilized to examine vulnerabilities in the

application. It analyzes web apps to perform vulnerability assesment for cross-site scripting,
command injections, etc.

Security Audit/Review:

It is a cybersecurity testing approach that should be conducted on a regular basis. It enables

digital businesses to assess the existing security status of their app by identifying
vulnerabilities and security issues. It can either be accomplished manually or through
automated testing tools.

Penetration Testing:

Penetration testing (or pen testing) is a security testing procedure where an authorized cyber-
security expert tries to find and exploit vulnerabilities in an application. Penetration testing
types are – Internal, External, BlackBox, and GreyBox.

Red Teaming:

It is a more comprehensive characterization of penetration testing where the internal or external

group of security professionals simulate real-time attacks on the business. The security experts
evaluate the infrastructure without any initial knowledge. The exhaustive evaluation is based
on integrating various security controls of the organization.

Processes Involved in Web Application Security Testing

Web Application Security Testing involves several critical processes to identify vulnerabilities
and ensure a secure online environment. Let’s explore some of these key processes:

Brute Force Attack Testing: It evaluates the robustness of authentication mechanisms and
systematically attempts numerous password combinations to gain unauthorized access. By
simulating such attacks, security experts can assess the application’s resistance to these
malicious attempts, identifying potential weak points in password protection.

Password Quality Rules: Testing password quality rules ensures the application enforces
strong password policies. This involves examining whether the application mandates using a
mix of characters, numbers, and symbols. Evaluating password length, complexity
requirements, and expiration policies helps deter attackers from exploiting weak passwords.

Session Cookies: These are essential for authentication and maintaining user sessions. Security
testing involves assessing the encryption and secure transmission of session cookies. By
analyzing these cookies, testers can ensure that sensitive user data remains encrypted and that
cookies are well-protected against theft or tampering.
User Authorization Processes: User authorization testing scrutinizes the application’s
authorization mechanisms. This entails verifying that users are granted appropriate access
privileges based on their roles. It also includes checking whether unauthorized users are
correctly denied access to restricted areas of the application.

SQL Injection: SQL injection is a prevalent attack vector. Security testing involves
deliberately attempting SQL injection attacks to identify vulnerabilities. Testers try injecting
malicious SQL queries into input fields to determine whether the application is susceptible to
unauthorized access or data breaches.

Trending Web Application Security Testing Tools in 2023

Security Incident Response Planning

 Many organizations believed that security incidents were something that only happened
to others. The recent wave of cyberattacks against infrastructure components used by
thousands of organizations has exposed the fragility of information security in modern
businesses.
 The consequences of a successful cyberattack can range from a minor disruption of
business operations to crippling financial and legal costs, so when things do go wrong,
you need to know who should be doing what. An effective incident response plan is
vital to keep your actions organized and minimize operational risk.

How to Define Your Security Incident Response Process

 Your response will vary depending on the scope and type of incident. You will need to
react differently to, say, a phishing attack that installs malware in your local network
than to a data breach caused by an SQL injection.
 To make sure that your security policies cover all cases, it’s best to take an existing
incident response framework as the starting point for building your own process. If you
already have an overall cybersecurity framework, the incident response process should
be included in its scope and cover all areas of IT security, including web application
security.
Typical Incident Response Steps for Web Application Security

 The two most popular incident response frameworks come from NIST and SANS.
While they differ in how they group and name the phases of incident response, both
follow the same basic process. Based on this, here are six basic steps for incident
handling in web application security: Prepare, Detect, Contain, Address, Recover, and
Learn.

Step 1: Prepare

 Preparation is by far the most important stage of incident response. To secure your web
assets, you first need to know what assets you have – and surprisingly many
organizations don’t even know that. Similarly, to ensure data security, you need to
know what your data is, where it resides, who should have access to it, and how critical
it is to your business.
 Next, you need some kind of risk assessment process so you know what security events
and impacts you are preparing for. Depending on your policies and requirements, this
could involve formal threat modeling or a more informal approach to threat intelligence
and identifying the most likely attack vectors.
 In the preparation stage, you are likely to identify weaknesses or blind spots that you
need to address. For example, if you use a tool like Invicti to run asset discovery
followed by a vulnerability scan, you may find forgotten or unmaintained websites that
are vulnerable to attack. These issues will need to be addressed to reduce your attack
surface and close all the gaps, so you might call this Step 0: Prevent.
 Whatever you put in your incident response plan, you need someone to implement it
when things go wrong. Your incident response (IR) team will often simply be your IT
security team, though large organizations may have a dedicated computer security
incident response team (CSIRT). In either case, you will need to have specific team
members on call and ready to follow established procedures.

Step 2: Detect

 Web application attacks and data breaches are often only detected after many days or
even months – or not detected at all, especially if they have no direct impact on
operations. Careful logging and monitoring at the application level can help to detect
suspicious activity, such as repeated access attempts or unexpected user accounts being
created.
 You can use a security information and event management (SIEM) solution to
coordinate these monitoring efforts. Regular security testing using an accurate and up-
to-date web vulnerability scanner is also vital not only to prevent attacks but also to
find new vulnerabilities that attackers could already have exploited.

Step 3: Contain

After a web security incident is detected, your IR team needs to triage it and decide on the best
course of action to minimize short-term impact and prevent minor issues from escalating into
full-blown incidents. For example, if you detect that a critical vulnerability in one of your
business applications is being actively exploited, the containment phase might involve setting
up your web application firewall (WAF) to block this specific attack and prevent any further
damage. Advanced vulnerability scanners like Invicti can even integrate with popular WAF
platforms to do this automatically.

Step 4: Address

 Once the immediate threat is under control, you need to fix or otherwise address the
issue permanently. Continuing the example of your critical vulnerability, after
deploying a WAF rule to block attacks in the containment phase, your security team
would take the vulnerability report and create a fix ticket for developers. In the case of
Invicti, this process can also be automated to streamline communication and minimize
the response time.
 Recent global cyberattacks have served as a reminder that plugging security holes is
often the easiest part. Advanced threat actors don’t do hit-and-run attacks but rather
infiltrate target systems to maintain a stealthy and persistent presence. Eliminating the
entry point is only the start of a long and arduous process where your IT security and
administrators check all potentially affected systems for malicious code such as web
shells and then clean or rebuild them.
 If you’ve had a data breach, you may also have legal obligations to take care of, such as
GDPR-mandated notifications. Depending on the type of data and your jurisdiction and
industry, you might need to report the incident to law enforcement or the relevant
regulatory bodies and update this notification as more information becomes available.

Step 5: Recover

 While most web application security incidents won’t require a full disaster recovery
process, you need to have incident recovery procedures in place for every eventuality
and every level of the application stack.
 In IT security, everything is connected, so a web application breach could be just one
part of a wider attack that affects other systems or threatens business continuity.
Regardless of the incident, the overriding goal of your recovery process should be to
restore normal service while minimizing damage and disruption to business operations.

Step 6: Learn

 Once the fire is out, you can move to post-incident activities such as a post-mortem or
root cause analysis. This phase is probably the most important for improving long-term
security since many web attacks are performed by reusing and adapting existing
techniques.
 For example, fixing only a specific injection vulnerability without actually making the
relevant part of the application code more secure may allow attackers to modify the
attack payload slightly and breach the application again. By analyzing each incident
and drawing the right lessons, you can go back to step 1 – and be better prepared for the
next attack.
Microsoft Security Development Lifecycle (SDL)

 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.
CLASP — Comprehensive, Lightweight Application Security Process — is an activity-driven,
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; riskassessment.

• 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

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 The following diagram depicts a recommended position of the Use Cases
within the CLASP process:
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.
 The Open Web Application Security Project (OWASP) has developed a useful framework for
this purpose in the form of the Software Assurance Maturity Model SAMM. It enables
companies not only to measure the maturity of their software development processes in terms
of security but also to iteratively improve.
Maturity Model

 The current version of the model (v2) is based on a set of 15 security practices grouped
into five core areas of business functions. Governance, design, implementation,
verification, and operations.
 Based on a detailed catalog of questions, companies can determine their maturity level
not only per individual activity but also aggregated to the respective areas and the entire
development process.
 In addition to the evaluation of the actual situation, an evaluation of the maturity
development over time can be presented, which enables the visualization of the project
progress and a comparison with the targeted milestones.
 The maturity model is agnostic in terms of techniques and development methodology,
but a certain affinity to agile development methods cannot be denied.
 Initial maturity graph for a startup

Governance

 The governance chapter aims at key performance indicators (KPIs) which enables
teams to see if they have achieved the targeted progress and where intervention is
[Link], it covers the policy and compliance of projects and the suppliers
of third-party components.
 Well-trained and motivated employees are a key factor for a successful security
program. These security champions are not only characterized by their interest and
knowledge in the security topic but are also communicative and actively contribute to a
positively reinforced security culture.

Design

 The security activities in the design phase involve defining security requirements,
creating a security architecture, and performing threat modeling.
 The goal is to find out what threats are affecting the application being developed and
whether they are being handled appropriately.
 Balanced medium maturity

Implementation

 In this chapter, SAMM focuses on the tools to integrate security into the build and
deployment [Link] address the secure handling of credentials to minimize
human involvement during initial setup and the subsequent renewal of secrets.
 While being important throughout the development lifecycle, the management of
defects is also handled in the implementation questions.
Verification

 Promoting software into the production environment without prior quality assurance
has become unthinkable in many areas. This applies in particular to security [Link]
chapter recommends security checks that are based on concrete security requirements
but generic tests still have their justification.
 SAMM places a emphasis on denial of service benchmarks, fuzzing, regression testing
for fixed vulnerabilities, and test automation in the build and deployment [Link] is
important not to lose sight of the appropriateness of the tests for the specific application
criticality.

Solid maturity with a opportunity for improvement in the verification section

Operation

 With DevOps, the boundaries of the software development process are increasingly
beginning to blur. The maturity model adds a separate section for [Link]
specifications tolerate manual log analysis, ad hoc responses to incidents, and best
efforts to detect attacks at a low maturity level.
 Improved maturity requires a dedicated incident response team and defined processes
for the detection and remediation of incidents. Patch management and configuration
hardening have clear recommendations for regular and systematic activities across the
entire technology stack.
 The highest score points in SAMM require the rapid decommissioning of outdated
applications or strategies to monitor such systems until they are replaced with modern
successors.