The document outlines an approach to application security that involves establishing a software security roadmap. It discusses assessing maturity, defining a security-enhanced software development lifecycle (S-SDLC), and implementing security activities such as threat modeling, secure coding practices, security testing, and metrics. The goal is to manage software risks through a proactive and holistic approach rather than just reacting to vulnerabilities.
Application Security - Your Success Depends on itWSO2
Traditional information security mainly revolves around network and operating system (OS) level protection. Regardless of the level of security guarding those aspects, the system can be penetrated and the entire deployment can be brought down if your application's security isn't taken into serious consideration. Information security should ideally start at the application level, before network and OS level security is ensured. To achieve this, security needs to be integrated into the application at the software development phase.
In this session, Dulanja will discuss the following:
The importance of application security - why network and OS security is insufficient.
Challenges in securing your application.
Making security part of the development lifecycle.
To Support Digital India, We are trying to enforce the security on the web and digital Information. This Slides provide you basic as well as advance knowledge of security model. Model covered in this slides are Chinese Wall, Clark-Wilson, Biba, Harrison-Ruzzo-Ullman Model, Bell-LaPadula Model etc.
Types of Access Control.
The state of being protected against the unauthorized use of information, especially electronic data, or the measures are taken to achieve this.
"the growing use of mobile applications is posing a risk to information security"
Security is the first concerning criteria in software development. Here, we will know about the role of developer and information security staff. The Secure Software development model (S-SDLC) is also described here.
Application Security - Your Success Depends on itWSO2
Traditional information security mainly revolves around network and operating system (OS) level protection. Regardless of the level of security guarding those aspects, the system can be penetrated and the entire deployment can be brought down if your application's security isn't taken into serious consideration. Information security should ideally start at the application level, before network and OS level security is ensured. To achieve this, security needs to be integrated into the application at the software development phase.
In this session, Dulanja will discuss the following:
The importance of application security - why network and OS security is insufficient.
Challenges in securing your application.
Making security part of the development lifecycle.
To Support Digital India, We are trying to enforce the security on the web and digital Information. This Slides provide you basic as well as advance knowledge of security model. Model covered in this slides are Chinese Wall, Clark-Wilson, Biba, Harrison-Ruzzo-Ullman Model, Bell-LaPadula Model etc.
Types of Access Control.
The state of being protected against the unauthorized use of information, especially electronic data, or the measures are taken to achieve this.
"the growing use of mobile applications is posing a risk to information security"
Security is the first concerning criteria in software development. Here, we will know about the role of developer and information security staff. The Secure Software development model (S-SDLC) is also described here.
This training creates the awareness of the security threats facing individuals, business owner’s, and corporations in today’s society and induces a’ plan-protection’ attitude. It enriches individuals, students’, business owners’ and workers’ approach to handling these threats and responding appropriately when these threats occur.
Intrusion detection and prevention systemNikhil Raj
This presentation describes how to implement Network based Intrusion Detection System (SNORT) in the network. Detecting and analyzing alerts generated and blocking the Attacker using Access Control List.
Secure Software Development Lifecycle - Devoxx MA 2018Imola Informatica
Slides from our talk @Devoxx MA 2018.
We discuss Secure Software Development Lifecycle practices, recommendations, and tools, and we show practical examples of bad progamming habits that can be mitigated.
The presentation describes basics of cryptography and information security. It covers goals of cryptography, history of cipher symmetric and public key cryptography
This training creates the awareness of the security threats facing individuals, business owner’s, and corporations in today’s society and induces a’ plan-protection’ attitude. It enriches individuals, students’, business owners’ and workers’ approach to handling these threats and responding appropriately when these threats occur.
Intrusion detection and prevention systemNikhil Raj
This presentation describes how to implement Network based Intrusion Detection System (SNORT) in the network. Detecting and analyzing alerts generated and blocking the Attacker using Access Control List.
Secure Software Development Lifecycle - Devoxx MA 2018Imola Informatica
Slides from our talk @Devoxx MA 2018.
We discuss Secure Software Development Lifecycle practices, recommendations, and tools, and we show practical examples of bad progamming habits that can be mitigated.
The presentation describes basics of cryptography and information security. It covers goals of cryptography, history of cipher symmetric and public key cryptography
Link to Youtube video: https://youtu.be/OJMqMWnxlT8
You can contact me at abhimanyu.bhogwan@gmail.com
My linkdin id : https://www.linkedin.com/in/abhimanyu-bhogwan-cissp-ctprp-98978437/
Threat Modeling(system+ enterprise)
What is Threat Modeling?
Why do we need Threat Modeling?
6 Most Common Threat Modeling Misconceptions
Threat Modelling Overview
6 important components of a DevSecOps approach
DevSecOps Security Best Practices
Threat Modeling Approaches
Threat Modeling Methodologies for IT Purposes
STRIDE
Threat Modelling Detailed Flow
System Characterization
Create an Architecture Overview
Decomposing your Application
Decomposing DFD’s and Threat-Element Relationship
Identify possible attack scenarios mapped to S.T.R.I.D.E. model
Identifying Security Controls
Identify possible threats
Report to Developers and Security team
DREAD Scoring
My Opinion on implementing Threat Modeling at enterprise level
CompTIA CySA Domain 1 Threat and Vulnerability Management.pptxInfosectrain3
The CompTIA Cybersecurity Analyst (CySA+) certification is the industry standard for demonstrating that cybersecurity professionals can analyze data and interpret the results to detect vulnerabilities, threats, and risks to an organization.
ОЛЬГА АКСЬОНЕНКО «Безпечна розробка програмного забезпечення в Agile проектах...QADay
Online Quality Assurance Day 2020 #2
ОЛЬГА АКСЬОНЕНКО
«Безпечна розробка програмного забезпечення в Agile проектах»
telegram: wwww.t.me/goqameetup
fb: www.fb.com/goqaevent
fb: www.fb.com/qaday.org
Сайт: www.qaday.org
Agenda:
- SDLC vs S-SDLC
- Mobile development security process
- What tools using for security testing?
- How to integrate into existing processes?
- What additionally you can do?
Threat modeling is an approach for analyzing the security of an application.
It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application
Threat modeling is not an approach to reviewing code, but it does complement the security code review process.
The inclusion of threat modeling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning.
Key Metrics and Process in Cyber Security Case Scenario for:
Identity & Access Management
Secure SDLC & Application Security
Endpoint Security
Vulnerability Management
This helps tell a story across the business process and the comparison of different vendors.
Business analysis activities for an
analyst. This PPT will help to understand how to analyze a business requirement preparation like business case, BRD and SRS.
Why LINQ?
LINQ Query & Method Syntax
Anatomy of the Lambda Expression
Standard Query Operators:
Expression in LINQ
Expression Tree
Immediate Execution of LINQ Query
let & into keyword
Sample LINQ Queries
About Controller
Action & Parameter
About Global.asax file
Method Corresponding to Event That Fire on Each Request
Method Corresponding to Event That Do Not Fire on Each Request
About Routing Engine in Asp.net MVC
Action Result Type
Redirect Permanent, Redirect Action, Redirect Route, File & Jeson
OOP Concept
How to create MVC
MVC application folder structure
About View bags
View bags vs View data Vs Temp Data
Layout Configuration
MVC application sample using Entity framework-EF
OOP Concept.
Industrial Training at Shahjalal Fertilizer Company Limited (SFCL)MdTanvirMahtab2
This presentation is about the working procedure of Shahjalal Fertilizer Company Limited (SFCL). A Govt. owned Company of Bangladesh Chemical Industries Corporation under Ministry of Industries.
Water scarcity is the lack of fresh water resources to meet the standard water demand. There are two type of water scarcity. One is physical. The other is economic water scarcity.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
Overview of the fundamental roles in Hydropower generation and the components involved in wider Electrical Engineering.
This paper presents the design and construction of hydroelectric dams from the hydrologist’s survey of the valley before construction, all aspects and involved disciplines, fluid dynamics, structural engineering, generation and mains frequency regulation to the very transmission of power through the network in the United Kingdom.
Author: Robbie Edward Sayers
Collaborators and co editors: Charlie Sims and Connor Healey.
(C) 2024 Robbie E. Sayers
Student information management system project report ii.pdfKamal Acharya
Our project explains about the student management. This project mainly explains the various actions related to student details. This project shows some ease in adding, editing and deleting the student details. It also provides a less time consuming process for viewing, adding, editing and deleting the marks of the students.
7. 7
Holistic View: Software vs. Application
Security
Security applied
by catch and
patches
Security built
into each phase of
the SDLC
Look at root
problem
causes
Look at
external
symptoms
Reactive,
Incident Response,
Compliance
Proactive,
Threat Modeling,
Secure Code Reviews
14. 14
Security Requirements
Encompasses both functional requirements for
security controls and risk mitigation driven
requirements from the abuse case scenarios
Define Security Requirements in Standards
Which controls are required (e.g. authentication,
authorization, encryption etc)
Where should be implemented (e.g. design, source code,
application, server)
Why are required
Compliance and auditing
Mitigation for known threats
How should be implemented and tested
15. 15
Functional and Non Functional Requirements
Functional Requirements:
Define the expected functionality of security controls
Depends on the applicable standards, policies and
regulations
Positive statements
“the application will lockout the user after 6 failed logon
attempts”
“passwords need to be 6 min characters, alphanumeric”
Risk Driven Security Requirements
Address all common vulnerabilities
Can be derived by use (or misuse) cases
Negative statements
The application should not allow of the data being altered or
destroyed
The application should not be compromised or misused for un-
authorized financial transaction by a malicious user.
18. 18
Threat Modeling
Categorizes the threats to the
application, highlights potential
vulnerabilities and identifies
countermeasures to be developed
Use a systematic fact based and
methodical approach:
1. Scope Assessment
Requirements, Use Cases
1. System Modeling
Physical and Logical View, Data Flows, Trust
Boundaries, Entry Points
1. Threat Identification
STRIDE, ASF
1. Threat Vulnerabilities and Attacks
Checklists, Attack Vulnerability Mapping
1. Identification of Countermeasures
Security Controls
1. Threat Prioritization and Risk Ranking
Risk Modeling
23. 23
Security Design Reviews
Objective is promote secure design and identify
of potential flaws before construction phase
Secure Architecture Review Process
Review High Level Design documents and verify that
security controls requirements are documented
Engage with:
Architects
Application Security Experts
Provide guidance on security technology/design
patterns
Identify potential gaps in security controls with threat
modeling
25. 25
Secure Coding Standards/Guidelines
Describe secure coding requirement in terms of:
1. The common vulnerabilities (e.g. OWASP
T10)
2. The issue type (e.g. Application Security
Frame)
3. The security threat or how can be
exploited
4. The in-secure code root cause of the
vulnerability
5. The “How to” find the vulnerability with
black box and white box testing
6. The secure coding
requirement/recommendation
26. 26
Example SQL Injection - Secure coding
requirements
Use SQL parameterized queries, avoid
dynamic SQL generation:
SELECT * FROM users WHERE username=?
JAVA EE use strongly typed “PreparedStatement”
in .NET use “SqlCommand” with “SqlParameters”
Sanitize input, remove special characters:
' " ` ; * % _ =&|*?~<>^()[]{}$nr
Use custom error messages:
No SQL exception information in error messages
27. 27
Secure Code Reviews
Objectives:
Identification of security issues in source code, the type of the
issue, the severity and recommendation on how should be fixed
Can be used to validate secure coding standards
Security assessment before releasing to QA and
production
Methodologies:
Automated Focused Source Code Analysis
Focus is on validation of false positives and auditing of
automated scan results
Manually Focused Secure Code Review
Focus is on identification of security issues as bugs vs. flaws
by categorizing the issues by type of vulnerability introduced
30. 30
Security Testing
Develop security test cases
Positive functional security test cases
Negative test cases (from use and misuse cases)
Common vulnerabilities exposure
Integrate Tests in Developers and Testers
Workflows
Static and Dynamic Testing, Unit Tests
Integrated System Tests and Operational Tests
Analyze and report test data
Defect Management
Root Cause Identification
31. 31
Security Testing Example: XSS
Define Test Case
Test login web page for XSS
Testing Procedure
Type the following strings in input
fields
<script>alert()</script>;
javascript:alert()
+ADw-SCRIPT+AD4-alert();+
Pass: Input validation Error is
through to the user
Fail: an alert dialog box is seen in
the browser window.
34. 34
Secure Deployment And Configuration
Items
Ensure the server configuration is secure
Only essential services, server hardening policies
Protect Access To Application Files/Data
XML files, property files, scripts, databases, directories
Enable Auditing And Logging
Enable all secure auditing and logging, protect logs
Enforce Change Management Controls
Don’t allow configuration changes without oversight
Audit configuration data
Release Securely
Don’t allow releases to ship without a security review
36. 36
Application Security Defect Tracking and
Metrics
Define where and how security metrics is collected
Tracking security defects throughout the SDLC
Report the root causes: requirements, design, code,
application
Report the type of the issues, the severity and whether
has been fixed or no
Metrics
What lifecycle stage are most flaws originating in?
What security mechanisms/controls are we having trouble
implementing?
What security vulnerabilities are we having trouble fixing?
37. 37
Examples of Application Security Metrics
Process Metrics
Is a SDL is used are security
gates enforced?
Is code validated against
security standards?
Security posture of a new
application before delivery
Security Officers Sign Off?
Test For Security
Vulnerabilities Executed?
All high risk issues closed?
Risk assessments completed?
% of developers trained, using
organizational security best
practice technology,
architecture and processes
Management Metrics
% of applications rated
“business-critical” that have
been security tested
% of projects that where
developed with the SDL
% of security issues identified
by lifecycle phase
% of issues whose risk has
been accepted
% of security issues being
fixed
Average time to correct
vulnerabilities
Business impact of critical
security incidents.
38. 38
Security Metrics Goals The Good and The Bad
Good: if goals when are “SMART” that is Specific,
Measurable, Attainable, Realistic, Traceable and
Appropriate
Example: reducing the overall number of vulnerabilities by
30% by fixing all low hanging fruits with source code analysis
during construction
Bad: if the goals justify the means to obtain the goals
40. 40
Business Cases for Your Organization
Tie the metrics to the business cases and support the
project stakeholders agendas:
Developer Leads: show that software can be build more
securely and efficiently
Project Managers: shows that projects are on schedule and
moving on target for the delivery dates and are getting better
during tests
Information Security Officers: provides a level of assurance
that security standard compliance is addressed through the
security review processes within the organization.
Benefits:
Cost savings
Risk measurement and reduction
Compliance reporting
41. 41
Business Cases And Software Security
StrategyBe realistic on what can be achieved
Organization is not yet ready (e.g. mature)
Engineers are not trained in software security
There are no tools available
Adapt the strategy to reality
Build upon your company strenghts
Get stakeholders buy in (CIOs, ISOs, PM, Developers,
Architects)
Set achieveable goals: reduce 30% of vulnerabilities
found through ethical hacking via source code analysys
Perform a gap analysis and proceed with process
improvement cycles:
Tailor to the initiative to the company culture
Be risk management driven
Introduce metrics and prove results
Editor's Notes
I plan to start at 2.30 and finish at 3 PM
Parlero degli scenari di incidenti delle risposte a tali incidenti e delle strategie per remdiare nel long term. Parlero anche di come creare “consapevolezza” e della
Software security initiative.
There are bad guys and good guys and some they just looking for work, be careful of responsible disclosure going public with a zero day can go against you. On the other hand also ignoring the vulnerabilities you are suppose to fix is not a very responsbile approach
The most common approach to finding vulnerabilities is to analyze the running application. The two techniques are “vulnerability scanning” (using tools and signature databases) and “penetration testing” (custom testing by experts). However, for many types of problems, analyzing the running application is very time-consuming and inaccurate. SQL injection, for example, is very difficult to find and diagnose in a running application, but can be quickly found by analyzing the source code.
The other approach is to analyze the source code. Like pentesting, this can be done manually (source code review) or with tools (static analysis). Code-based approaches have a reputation for being expensive and time-consuming, but this reputation is unfounded. For many types of issues, using the code is many times faster and more accurate than penetration testing.
The most cost-effective approach to application security is a “combined” or “integrated” approach. The assessor should be encouraged to use the most appropriate tool to find problems in the most cost-effective manner. For example, an assessor may notice a potential vulnerability during a penetration test, automatically scan the code for possible instances of the problem, and then confirm using code review.
Note that the purely automated approaches (scanning and static analysis) are especially ineffective for application security (most experts put the effectiveness of pure scanning or static analysis at less than 20%). This is largely due to the custom nature of applications. Because each one is different, there is no database of signatures the automated tools can use.
Ultimately a mature software security process blends both information risk management and software engineering processes in a software security framework. For example, threat modeling will identify threats and technical impacts during design that are used as a factor along with business impact in the calculation of the overall risk. Ideally, such mature software security process should integrate software security activities in each phase of the SDLC. This also included activities that are performed as part of the operation life-cycle such as patch and incident management as well foundational activities such as metrics and measurements and security training and awareness.
Ideally, for a software security framework to be useful in practice, it needs to apply to the different software development methodologies used by your organization. This might include evolutionary-interactive software life-cycles such as spiral, RUP, XP and Agile besides the traditional waterfall model but also.
In case of RUP and Agile for example this means that such software security best practices need to be iterated as the software evolves and reviewed at each interaction depending on the available artifacts.
Another pre-condition is focusing on software security awareness that is communicating to the project stakeholders what software security entitles to that is when and how security needs to be applied to the application, in better terms explaining the difference between application and software security.Applications vs. software are best described as the Chinese philosophy “yin” and “yang” concepts: opposing and, at the same time, complementary (completing) aspects of any one software development process when seen from different perspectives. For example, from the “when” perspective is applying security after application is already build vs. while the application is being build, from the problem solution perspective is looking at the sympthoms instead of the root causes, from the approach perspective is catch and patch vs. building security throughout the software life cycle and from the risk perspective is reactive response to security incidents via implementation of “band-aid” solutions vs. proactive threat analysis, risk assessment and implementation of countermeasures as necessary.
So you need a road map, start with assessing the maturity of the PPT in place, then definition of the processes to build security into the SDLC and the security activities. Then you cannot manage if you do not measure and risk menagement expecially needs vulnerability metrics for example. Finally you can make the case with your data and set objectives moving forward.
Essential elements: Verification check points, developer’s training and tools.
The aim of the Software Development Lifecycle SDL is to integrate tasks and checkpoints in the software development organization’s processes so that software security can be improved with well defined security reviews and security deliverables. Critical to the effectiveness of the SDL implementation is the ongoing education and training for software developers and the techniques and technologies required for secure development. Figure 2 depicts at high level the phases of the SDL and the software security activities:
Figure 2: MS SDL
The SDL software security activities (the yellow blocks) map to the SDLC (the big arrows) such as:
Definition of security feature requirements during the requirements phase
Security architecture design, best practices and threat modeling during design
Static analysis via automation tools during implementation
Application of coding and testing standards during implementation
Code reviews during implementation
Security focused testing, pen and fuzz testing, during the verification phase
Security servicing and response during operations (post release)
Pro and Cons:
Con: Threat analysis as is done in the MS SDL is very product oriented and static because is build around the Microsoft risk model STRIDE/DREAD. This risk model might work well for a software development shop and for shrink wrapped software development but it will not be suitable for applications developed for organizations that use proprietary risk management models such as financial and banking institutions for example.
Pro: Microsoft products that have adopted the SDL such as SQL Server 2003, Vista and IE6 had significant less security issues then products that did not use it. This is data validated by comparing with the number of vulnerabilities in software versions developed prior to the introduction of the SDL: software developed under the SDL have exhibited over a 50% reduction in vulnerabilities
Pro: The SDL methodology is adequately supported by tools such as threat modeling and source code analysis tools. Some of these tools (e.g. Prefix and Prefast) are part of Microsoft Integrated Development Environment for which a license is needed while others are free (e.g. ACE Torpedo TM). So far SDL is the only security-enhanced lifecycle process model that support threat analysis with a tool.
Pro: MS SDL is very well documented, easily accessible via MSDN web site and very extensive including secure software handbooks for developers, threat and countermeasures guidelines and checklists etc.
Security will need to be baked into each of the development steps as well, but that will not be the primary focus on that particular step. Particularly for the acceptance tests and QA steps.
OWASP believes that clearly articulating an application security requirements guide detailing both high-level and specific requirements is the best way to ensure that a strong, robust yet workable guide can become default in all aspects of application security.
Take LMCO standard and tailor it
Refine: “You will do access control”
Into: This is the access control matrix & this is how it will be enforced.
- we will use netegrity to implement this policy
Adaptation of a proven object-oriented modeling technique, use cases, to capture and analyze security requirements in a simple way.
We define a use case as a specification of a type of complete interaction between a system and one or more actors.
We define an abuse case as a specification of a type of complete interaction between a system and one or more actors, where the results of the interaction are harmful to the system, one of the actors, or one of the stakeholders in the system.
The graphical example in Figure TBD depicts the derivation of security requirements via use and and misuse cases. The functional scenario consists on the user action: entering username and password and for the application actions: authenticate the user and provide for an error message if validation fails. The misuse case consists on the actions: hacker trying to break authentication by brute forcing the password via a dictionary attack and by guessing the valid username from the error messages. By graphically representing the threats to the user actions (misuses) it is possible to derive the countermeasures as the application actions that mitigate such threats.
Threat modeling implies a view of the architecture in terms of users accessing assets (web servers, data) through protocols crossing trust boundaries.
It is a king of end to end data flow schematic. The notation is not important, rather to be comprehensive enough to identify gaps in controls and countermesures.
Threat is un-authorized access to data, the vulnerability can be leaving the computer un-attended via shared terminal, a SQL injection attack, elevation of privileged from a logged session or simply access to data from the browser that allows you to get to the data.
All the orange ones are vulnerabilities while the green ones are the countermeasures
Data flows diagrams and attack trees (threat definition) and secure requirements (Scope definition) all feed the threat model.
The result is the identification of threats, the risk of such threats and the countermeasures that mitigate such threats.
The threat model is also used for secure code reviews as a why to determine along with secure coding standards that threats are mitigated.
Not trying to reinvent the whole SDLC, just trying to insert a few key activities that will help generate more secure code.
Once you have decided the categorization, that is STRIDE, ASF, MITRE CVE etc you need to document the vulnerability and the type
By describing the security threat you help the developer to understand how an attacker can exploit the vulnerability (real example in plain english)
The software root cause is the an example of offending security defect, the how to should cover both white box and black box depending if the code is already integrated as part of the application, the countermeasure is the code fix, configuration change, design change and the risk rating is the assigned value to the risk of the vulnerability
Find issues
Validate standards
Act as a gateway
There is not such a thing like a fully automated process, false positives need to be validated. A manually focused source code analysis can find more issues than automated validation only
Validation of false positives, tools provide knowledge to the developers and point to root causes. The validation is in terms of relevance, some issues are quality issues
Security testing as part of the testing workflow is still in his infancy
If the requirements (Security) are written down the normal testing process should work.
General testing procedures can be adapted for security tests. Some can be conducted manually some need the help of tools
Discussion? Security flaws are often sensitive. Should they be treated differently
Combine looking for quick wins while setting out a roadmap