This document outlines an approach to application security that involves assessing maturity, defining a software security roadmap, and implementing security activities throughout the software development lifecycle (SDLC). It discusses security requirements, threat modeling, secure design guidelines, coding standards, security testing, configuration management, metrics, and making business cases to justify security investments. The goal is to manage software risks proactively by building security into each phase rather than applying it reactively through patches.
The document discusses approaches to building secure web applications, including establishing software security processes and maturity levels. It covers security activities like threat modeling, defining security requirements, secure coding standards, security testing, and metrics. Business cases for software security focus on reducing costs of vulnerabilities, threats to web apps, and root causes being application vulnerabilities and design flaws.
This document provides an introduction to the concepts of software security. It discusses how security vulnerabilities in software can enable attacks. The goals of the course are explained as helping students understand the nature of software security vulnerabilities, principles of secure software development, and techniques for security testing, analysis, and prevention of vulnerabilities. The lecture topics are outlined and assignments are described, including threat modeling, security policy design, and analyzing buffer overflow attacks and web application vulnerabilities.
This document discusses software security engineering. It covers security concepts like assets, vulnerabilities and threats. It discusses why security engineering is important to protect systems from malicious attackers. The document outlines security risk management processes like preliminary risk assessment. It also discusses designing systems for security through architectural choices that provide protection and distributing assets. The document concludes by covering system survivability through building resistance, recognition and recovery capabilities into systems.
The document discusses starting a software security initiative within an organization using a maturity-based and metrics-driven approach. It recommends assessing the current maturity level, defining security standards and processes, and implementing security activities throughout the software development lifecycle (SDLC). Key metrics to track include the percentage of issues identified and fixed by lifecycle phase, average time to fix vulnerabilities, and vulnerability density.
The document discusses technical vulnerability management and outlines the key steps in the NIST Risk Management Framework that include vulnerability analysis. It also covers establishing an effective Patch and Vulnerability Group to monitor for vulnerabilities, prioritize remediation, and deploy patches. Finally, it provides examples of different types of vulnerability analysis tools including network scanners, host scanners, and web application scanners.
The document provides guidance on creating a business case for software security initiatives by estimating costs and benefits. It discusses estimating failure costs from vulnerabilities versus assumption costs of security measures. Metrics like the vulnerability lifecycle and maturity models can demonstrate security improvements. The business case should quantify risk reduction through qualitative and quantitative analysis to show initiatives are cost-beneficial.
This document presents SAVI (Static Analysis Vulnerability Indicator), a method for ranking the vulnerability of web applications using static analysis of source code. SAVI combines results from several static analysis tools and vulnerability databases to calculate a metric called Static Analysis Vulnerability Density (SAVD) for each application. The authors tested SAVI on several open source PHP applications and found SAVD correlated significantly with future vulnerability reports, indicating static analysis can help identify post-release vulnerabilities.
The document discusses approaches to building secure web applications, including establishing software security processes and maturity levels. It covers security activities like threat modeling, defining security requirements, secure coding standards, security testing, and metrics. Business cases for software security focus on reducing costs of vulnerabilities, threats to web apps, and root causes being application vulnerabilities and design flaws.
This document provides an introduction to the concepts of software security. It discusses how security vulnerabilities in software can enable attacks. The goals of the course are explained as helping students understand the nature of software security vulnerabilities, principles of secure software development, and techniques for security testing, analysis, and prevention of vulnerabilities. The lecture topics are outlined and assignments are described, including threat modeling, security policy design, and analyzing buffer overflow attacks and web application vulnerabilities.
This document discusses software security engineering. It covers security concepts like assets, vulnerabilities and threats. It discusses why security engineering is important to protect systems from malicious attackers. The document outlines security risk management processes like preliminary risk assessment. It also discusses designing systems for security through architectural choices that provide protection and distributing assets. The document concludes by covering system survivability through building resistance, recognition and recovery capabilities into systems.
The document discusses starting a software security initiative within an organization using a maturity-based and metrics-driven approach. It recommends assessing the current maturity level, defining security standards and processes, and implementing security activities throughout the software development lifecycle (SDLC). Key metrics to track include the percentage of issues identified and fixed by lifecycle phase, average time to fix vulnerabilities, and vulnerability density.
The document discusses technical vulnerability management and outlines the key steps in the NIST Risk Management Framework that include vulnerability analysis. It also covers establishing an effective Patch and Vulnerability Group to monitor for vulnerabilities, prioritize remediation, and deploy patches. Finally, it provides examples of different types of vulnerability analysis tools including network scanners, host scanners, and web application scanners.
The document provides guidance on creating a business case for software security initiatives by estimating costs and benefits. It discusses estimating failure costs from vulnerabilities versus assumption costs of security measures. Metrics like the vulnerability lifecycle and maturity models can demonstrate security improvements. The business case should quantify risk reduction through qualitative and quantitative analysis to show initiatives are cost-beneficial.
This document presents SAVI (Static Analysis Vulnerability Indicator), a method for ranking the vulnerability of web applications using static analysis of source code. SAVI combines results from several static analysis tools and vulnerability databases to calculate a metric called Static Analysis Vulnerability Density (SAVD) for each application. The authors tested SAVI on several open source PHP applications and found SAVD correlated significantly with future vulnerability reports, indicating static analysis can help identify post-release vulnerabilities.
Secure by design and secure software developmentBill Ross
This secure lifecycle management process (SLCMP said slickum) defines the basic and most realistic way to develop secure software. While the briefing is a bit dated slide 34 is still a very relevant process. What is below the green line is the security dynamic process that happens supporting the basic development process seen above the green line. SLCMP is supported by building a complementary and excellent information risk framework system security plan or IRASSP. SLCMP is operationally deployed.
As delusions of effective risk management for application environments continue to spread, companies continue to bleed large amounts of security spending without truly knowing if the amount is warranted, effective, or even elevating security at all. In parallel, hybrid, thought-provoking security strategies are moving beyond conceptual ideas to practical applications within ripe environments. Application Threat Modeling is one of those areas that, beyond the hype, provides practical and sensible security strategy that leverages already existing security efforts for an improved threat model of what is lurking in the shadows.
Tony UcedaVelez, Managing Director
An experienced security management professional, Tony has more than 10 years of hands-on security and technology experience and is a vocal advocate of security process engineering – a term that describes the design and development of secure processes and controls working symbiotically to create a unique business workflow. Tony currently serves as Managing Director for an Atlanta based risk advisory firm that focuses on security strategy and delivering effective means for risk mitigation and security process engineering. He has worked and consulted for the Fortune 500, as well as federal agencies in the U.S. on the topic of application security and security process engineering.
6 Most Popular Threat Modeling MethodologiesEC-Council
Threat modeling is one of the most effective preventive security measures, empowering cybersec professionals to put a robust cybersecurity strategy in place. So, let’s learn more about threat modeling in this SlideShare.
If you are keen to learn effective threat modeling after going through the SlideShare, click here: https://www.eccouncil.org/programs/threat-intelligence-training/
Rothke rsa 2012 building a security operations center (soc)Ben Rothke
This document discusses building a Security Operations Center (SOC). It outlines the need for a SOC to provide continuous security monitoring, protection, detection and response against threats. It then discusses the key components of an effective SOC, including real-time monitoring, reporting, post-incident analysis and security information and event management tools. Finally, it examines the considerations around choosing to build an internal SOC versus outsourcing to a managed security service provider.
The document discusses three standards used for classifying vulnerabilities: CVE, CWE, and CVSS. CVE provides identifiers for known vulnerabilities. CWE defines common weakness types. CVSS provides a scoring system to assess vulnerability severity levels. The Heartbleed bug is used as an example, which is identified by CVE-2014-0160, classified under CWE-200 for information exposure, and given a CVSS score of 6.4.
1. The document discusses threat modeling and security principles like reducing attack surface, defense in depth, and least privilege. It provides examples of how these principles can be applied, like turning off unused ports and services to reduce attack surface.
2. Defense in depth is explained as having multiple layers of defense so that if one layer is breached, the next prevents damage. An example is provided of how Windows Server 2003 was unaffected by a vulnerability through defense in depth techniques.
3. These include changes to the underlying code, default configuration differences, and additional protections like buffer overrun detection that together prevented exploitation even if the vulnerability was present.
The document summarizes an OWASP Kyiv Winter 2019 event on threat modeling. It discusses threat modeling approaches and tools like STRIDE, Threat Dragon, and the Microsoft Threat Modeling Tool. It provides an example of threat modeling a simple 3-tier application and outlines common threat categories like spoofing, tampering, and elevation of privilege. Contact information is also included for following up on threat modeling.
Matteo Meucci Software Security in practice - Aiea torino - 30-10-2015Minded Security
Matteo Meucci did a talk on software security in practice, describing the actual scenario and the roadmap for the enterprise to improve their maturity in the SDLC.
A successful application security program - Envision build and scalePriyanka Aash
Learn how to build an application security program that is successfully integrated into various stages of software development life cycle and product life cycle. This lab will draw from the facilitators’ successful experience at Sabre, focusing on the top five maxims to design, build and scale.
(Source : RSA Conference USA 2017)
This document discusses application threat modeling (ATM) as a systematic approach to identifying security risks in software applications. It describes how ATM can be used at different stages of the software development lifecycle, from requirements to design to testing. The key steps of ATM include decomposing the application, identifying threats and vulnerabilities, analyzing attack vectors, and determining mitigation strategies. ATM helps prioritize risks and supports decision making around risk acceptance, avoidance, or mitigation.
Most organizations require threat models. The industry has recommended threat modeling for years. What holds us back? Master security architect, author and teacher Brook Schoenfield will take participants through a threat model experience based upon years of teaching. Expect a kick start. Practitioners will increase understanding. Experts will gain insight for teaching and programs.
(Source : RSA Conference USA 2017)
The document discusses integrating software security into the software development lifecycle. It recommends addressing security as early as possible, including during the requirements phase by performing threat assessments and defining security requirements. During design, it suggests involving security experts, using threat modeling to understand risks, and implementing defenses like isolation, least privilege, and defense in depth. Throughout development and testing, it advises performing security reviews, testing, and activities to find and fix vulnerabilities before deployment.
This is a presentation discussing recommendations for a secure connection between a remote data center and a primary data center; taking into account user connectivity and end-user security awareness training.
The Security Vulnerability Assessment Process & Best PracticesKellep Charles
Conducting regular security assessments on the organizational network and computer systems has become a vital part of protecting information-computing assets. Security assessments are a proactive and offensive posture towards information security as compared to the traditional reactive and defensive stance normally implemented with the use of Access Control-Lists (ACLs) and firewalls.
Too effectively conduct a security assessment so it is beneficial to an organization, a proven methodology must be followed so the assessors and assesses are on the same page.
This presentation will evaluate the benefits of credential scanning, scanning in a virtual environment, distributed scanning as well as vulnerability management.
This document discusses network security and provides information on key security concepts. It covers prevention, detection, and response as the foundation of security. Integrity, confidentiality, availability, and authentication are discussed in detail. The document emphasizes that network security is as much about business processes and policies as technical controls. Overall prevention is the most important and cost-effective approach to security. Detection and response procedures should also be established in case preventative controls fail.
This document summarizes Miriam Celi's presentation on secure coding and threat modeling. The key points are:
1. Miriam Celi discussed secure coding principles and resources like CWE, CVE, and OWASP to help developers write more secure code. Threat modeling was presented as a way to identify risks and address them in the design process.
2. Threat modeling involves identifying threats, assets, and vulnerabilities in a system and making design decisions to mitigate risks. It is an iterative team activity that should be performed throughout development.
3. Resources like STRIDE, CAPEC, and Microsoft's threat modeling tool were presented to help structure the threat modeling process. Statistics on rising costs of
This document provides an overview of the Information Security Governance and Risk Management domain covered by the CISSP certification. It discusses key topics in this domain including information security concepts, risk management, policies, standards, procedures, data classification, risk assessment, and security controls. The document is divided into sections that define learning objectives, reference materials, and describe topics covered within the domain such as information security management, governance, classification, and the role of planning, policies, guidelines, standards, procedures, security training, and risk management practices and tools.
This document discusses security principles for protecting assets and their confidentiality, integrity, and availability. It defines security, risk management, threats, vulnerabilities, and exploits. It provides examples of asset types and security risks from hackers, system failures, and employees. It emphasizes applying risk management and defense in depth across software development lifecycles to identify and mitigate vulnerabilities through practices like requirements analysis, coding standards, testing and reviews.
The document discusses risk-based security testing methodology for web applications. It involves deriving test cases from threat analysis techniques like attack tree analysis and understanding real-world attack vectors. The goal is to simulate real attacker scenarios and test for vulnerabilities, as well as potential abuse of business logic or flaws in the secure architecture. Security testing is integrated into the software development lifecycle to find and fix issues early.
Secure by design and secure software developmentBill Ross
This secure lifecycle management process (SLCMP said slickum) defines the basic and most realistic way to develop secure software. While the briefing is a bit dated slide 34 is still a very relevant process. What is below the green line is the security dynamic process that happens supporting the basic development process seen above the green line. SLCMP is supported by building a complementary and excellent information risk framework system security plan or IRASSP. SLCMP is operationally deployed.
As delusions of effective risk management for application environments continue to spread, companies continue to bleed large amounts of security spending without truly knowing if the amount is warranted, effective, or even elevating security at all. In parallel, hybrid, thought-provoking security strategies are moving beyond conceptual ideas to practical applications within ripe environments. Application Threat Modeling is one of those areas that, beyond the hype, provides practical and sensible security strategy that leverages already existing security efforts for an improved threat model of what is lurking in the shadows.
Tony UcedaVelez, Managing Director
An experienced security management professional, Tony has more than 10 years of hands-on security and technology experience and is a vocal advocate of security process engineering – a term that describes the design and development of secure processes and controls working symbiotically to create a unique business workflow. Tony currently serves as Managing Director for an Atlanta based risk advisory firm that focuses on security strategy and delivering effective means for risk mitigation and security process engineering. He has worked and consulted for the Fortune 500, as well as federal agencies in the U.S. on the topic of application security and security process engineering.
6 Most Popular Threat Modeling MethodologiesEC-Council
Threat modeling is one of the most effective preventive security measures, empowering cybersec professionals to put a robust cybersecurity strategy in place. So, let’s learn more about threat modeling in this SlideShare.
If you are keen to learn effective threat modeling after going through the SlideShare, click here: https://www.eccouncil.org/programs/threat-intelligence-training/
Rothke rsa 2012 building a security operations center (soc)Ben Rothke
This document discusses building a Security Operations Center (SOC). It outlines the need for a SOC to provide continuous security monitoring, protection, detection and response against threats. It then discusses the key components of an effective SOC, including real-time monitoring, reporting, post-incident analysis and security information and event management tools. Finally, it examines the considerations around choosing to build an internal SOC versus outsourcing to a managed security service provider.
The document discusses three standards used for classifying vulnerabilities: CVE, CWE, and CVSS. CVE provides identifiers for known vulnerabilities. CWE defines common weakness types. CVSS provides a scoring system to assess vulnerability severity levels. The Heartbleed bug is used as an example, which is identified by CVE-2014-0160, classified under CWE-200 for information exposure, and given a CVSS score of 6.4.
1. The document discusses threat modeling and security principles like reducing attack surface, defense in depth, and least privilege. It provides examples of how these principles can be applied, like turning off unused ports and services to reduce attack surface.
2. Defense in depth is explained as having multiple layers of defense so that if one layer is breached, the next prevents damage. An example is provided of how Windows Server 2003 was unaffected by a vulnerability through defense in depth techniques.
3. These include changes to the underlying code, default configuration differences, and additional protections like buffer overrun detection that together prevented exploitation even if the vulnerability was present.
The document summarizes an OWASP Kyiv Winter 2019 event on threat modeling. It discusses threat modeling approaches and tools like STRIDE, Threat Dragon, and the Microsoft Threat Modeling Tool. It provides an example of threat modeling a simple 3-tier application and outlines common threat categories like spoofing, tampering, and elevation of privilege. Contact information is also included for following up on threat modeling.
Matteo Meucci Software Security in practice - Aiea torino - 30-10-2015Minded Security
Matteo Meucci did a talk on software security in practice, describing the actual scenario and the roadmap for the enterprise to improve their maturity in the SDLC.
A successful application security program - Envision build and scalePriyanka Aash
Learn how to build an application security program that is successfully integrated into various stages of software development life cycle and product life cycle. This lab will draw from the facilitators’ successful experience at Sabre, focusing on the top five maxims to design, build and scale.
(Source : RSA Conference USA 2017)
This document discusses application threat modeling (ATM) as a systematic approach to identifying security risks in software applications. It describes how ATM can be used at different stages of the software development lifecycle, from requirements to design to testing. The key steps of ATM include decomposing the application, identifying threats and vulnerabilities, analyzing attack vectors, and determining mitigation strategies. ATM helps prioritize risks and supports decision making around risk acceptance, avoidance, or mitigation.
Most organizations require threat models. The industry has recommended threat modeling for years. What holds us back? Master security architect, author and teacher Brook Schoenfield will take participants through a threat model experience based upon years of teaching. Expect a kick start. Practitioners will increase understanding. Experts will gain insight for teaching and programs.
(Source : RSA Conference USA 2017)
The document discusses integrating software security into the software development lifecycle. It recommends addressing security as early as possible, including during the requirements phase by performing threat assessments and defining security requirements. During design, it suggests involving security experts, using threat modeling to understand risks, and implementing defenses like isolation, least privilege, and defense in depth. Throughout development and testing, it advises performing security reviews, testing, and activities to find and fix vulnerabilities before deployment.
This is a presentation discussing recommendations for a secure connection between a remote data center and a primary data center; taking into account user connectivity and end-user security awareness training.
The Security Vulnerability Assessment Process & Best PracticesKellep Charles
Conducting regular security assessments on the organizational network and computer systems has become a vital part of protecting information-computing assets. Security assessments are a proactive and offensive posture towards information security as compared to the traditional reactive and defensive stance normally implemented with the use of Access Control-Lists (ACLs) and firewalls.
Too effectively conduct a security assessment so it is beneficial to an organization, a proven methodology must be followed so the assessors and assesses are on the same page.
This presentation will evaluate the benefits of credential scanning, scanning in a virtual environment, distributed scanning as well as vulnerability management.
This document discusses network security and provides information on key security concepts. It covers prevention, detection, and response as the foundation of security. Integrity, confidentiality, availability, and authentication are discussed in detail. The document emphasizes that network security is as much about business processes and policies as technical controls. Overall prevention is the most important and cost-effective approach to security. Detection and response procedures should also be established in case preventative controls fail.
This document summarizes Miriam Celi's presentation on secure coding and threat modeling. The key points are:
1. Miriam Celi discussed secure coding principles and resources like CWE, CVE, and OWASP to help developers write more secure code. Threat modeling was presented as a way to identify risks and address them in the design process.
2. Threat modeling involves identifying threats, assets, and vulnerabilities in a system and making design decisions to mitigate risks. It is an iterative team activity that should be performed throughout development.
3. Resources like STRIDE, CAPEC, and Microsoft's threat modeling tool were presented to help structure the threat modeling process. Statistics on rising costs of
This document provides an overview of the Information Security Governance and Risk Management domain covered by the CISSP certification. It discusses key topics in this domain including information security concepts, risk management, policies, standards, procedures, data classification, risk assessment, and security controls. The document is divided into sections that define learning objectives, reference materials, and describe topics covered within the domain such as information security management, governance, classification, and the role of planning, policies, guidelines, standards, procedures, security training, and risk management practices and tools.
This document discusses security principles for protecting assets and their confidentiality, integrity, and availability. It defines security, risk management, threats, vulnerabilities, and exploits. It provides examples of asset types and security risks from hackers, system failures, and employees. It emphasizes applying risk management and defense in depth across software development lifecycles to identify and mitigate vulnerabilities through practices like requirements analysis, coding standards, testing and reviews.
The document discusses risk-based security testing methodology for web applications. It involves deriving test cases from threat analysis techniques like attack tree analysis and understanding real-world attack vectors. The goal is to simulate real attacker scenarios and test for vulnerabilities, as well as potential abuse of business logic or flaws in the secure architecture. Security testing is integrated into the software development lifecycle to find and fix issues early.
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
The document provides an overview of key security engineering activities that should be integrated into the software development lifecycle (SDLC). It discusses securing each phase of development through threat modeling, secure coding practices like code reviews, and security testing. The goal is to build security into applications from the start to help prevent vulnerabilities and deliver more robust products.
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.
This document discusses the importance of secure application development and having a security development lifecycle (SDLC). It argues that application security cannot be bolted on after development, and that all developers need to understand security principles. The document outlines key aspects of a secure SDLC, including requirements, design, implementation, testing, code reviews, authorization enforcement, logging, error handling, and conclusions. The core theme is that secure applications start with good, tested code and having a mature development process in place.
ОЛЬГА АКСЬОНЕНКО «Безпечна розробка програмного забезпечення в 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
This document discusses different types of security assessments:
1) Technical security testing assesses security flaws through vulnerability assessments, network penetration testing, web application testing, and source code analysis.
2) Security process assessments evaluate weaknesses in security processes by reviewing frameworks like NIST CSF and COBIT.
3) Security audits involve compliance checks both internally and externally to verify proper security controls are in place.
The document provides an overview of Microsoft's Security Development Lifecycle (SDL) threat modeling process and tool. The SDL threat modeling process involves 4 main steps: 1) modeling the system, 2) enumerating potential threats, 3) identifying mitigations, and 4) validating the threat model. Threat modeling helps identify security risks early and guide other security activities. The Microsoft SDL Threat Modeling Tool supports collaboration on threat modeling and integrates with other SDL processes.
key metrics and process in cyber security case scenario Skillweed
This document discusses key concepts in identity and access management (IAM), secure software development lifecycle (SDLC) and application security, endpoint security, and vulnerability management. It provides definitions and descriptions of each topic, examples of metrics used to measure them, potential tools that can be used, and presents them from a management perspective.
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?
The document discusses application threat modeling for a college library website. It describes decomposing the application into external dependencies, entry points, assets, and trust levels. It then covers determining and ranking threats using STRIDE and ASF categorizations. The document outlines identifying security controls and countermeasures to address vulnerabilities. It provides steps for threat analysis and defining mitigation strategies.
This document proposes optimizing key IT domains including identity and access management, secure software development lifecycles, endpoint security, and vulnerability management. It discusses processes, metrics to track, and tools to use for each domain. The document provides generic best practices that can be customized for specific industries. It aims to help organizations choose good processes, metrics to measure effectiveness, and tools to implement controls in these important IT areas.
The document discusses web application security testing techniques. It covers topics like the difference between web sites and applications, security definitions, vulnerabilities like SQL injection and XSS, defense mechanisms, and tools for security testing like Burp Suite. The agenda includes discussing concepts, designing test cases, and practicing security testing techniques manually and using automated tools.
Application Security Testing for Software Engineers ,Developers and testersGustavo Nieves Arreaza
Gustavo Nieves Arreaza
1. Application Security Testing for Software Engineers ,Developers and testers.
2. Who Am I? • Software Engineer based in Chile • OWASP Viña del mar Chapter Leader • Recurrent Speaker on Application Security conferences • Head of Software Development
https://www.appsec.cl
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.
The document discusses LINQ (Language Integrated Query), which provides a uniform query syntax in C# and VB.NET to retrieve data from different sources. LINQ allows querying of objects, XML documents, SQL databases, and other data formats using the same basic coding patterns. It offers benefits like a familiar language, less coding, readable code, standardized querying across sources, compile-time type safety, and IntelliSense support. The document covers LINQ query syntax, method syntax using lambda expressions, standard query operators like Where, OrderBy, GroupBy, Join, and Aggregate functions. Examples are provided of LINQ queries and expression trees.
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.
Knowledge share about scalable application architectureAHM Pervej Kabir
This document discusses scalable web application architectures. It begins by defining scalability and explaining the objectives of scalable systems, including handling traffic and data growth while maintaining system maintainability. There are two main types of architectures discussed: network-based architectures and application-based architectures. Network-based architectures focus on load balancing and distributing traffic across servers, while application-based architectures separate an application into tiers or layers, with the most common being three-tier architectures using a model-view-controller (MVC) pattern. The document provides an overview of common scalability patterns including caching, databases, and file storage solutions.
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.
This document discusses key aspects of software project management including definitions of a project, common causes of project failure, and the importance of project management. It outlines several principles and processes of project management including defining needs and scope, planning, execution, control, and closing. It emphasizes managing people, products, processes, and the overall project. Effective project management focuses on understanding problems, maintaining momentum, tracking progress, making smart decisions, and conducting postmortem analyses.
The document provides an overview of the Capability Maturity Model Integration (CMMI) framework. CMMI is an industry standard for improving product quality and development processes. It consists of best practices for systems engineering, software engineering, integrated product and process development, and supplier sourcing. CMMI models an organization's processes at five maturity levels from initial to optimizing. Higher levels indicate more disciplined, defined, and quantitatively managed processes. The document outlines the CMMI components and structure, describes each maturity level and associated process areas, and discusses tips for successful CMMI implementation.
Scrum is an agile framework that focuses on rapid delivery of working software in short cycles called sprints. It consists of self-organizing cross-functional teams, regular sprints with daily stand-ups, and artifacts like a product backlog, sprint backlog, and burn-down charts. The process involves sprint planning, daily scrums, sprint reviews, and retrospectives. Scrum roles include the product owner who prioritizes the backlog, the scrum master who facilitates the process, and the development team.
1. To create a new household or edit an existing one, click buttons in the survey and current location windows to input identifying information and select sections.
2. To collect answers, select a language, question, and answer before moving to the next question or section. Other answers can be input in text fields.
3. For repetitive or dependent sections, select members and input their answers before finishing the section.
Automated Survey Data Received and Sync From FieldAHM Pervej Kabir
This document provides instructions for various user management and data transfer functions in a survey application. It includes steps for changing passwords, downloading and uploading questions and survey data between a web server and laptop, and downloading data from a connected PDA device. The document is organized into sections covering user management, downloading/uploading questions and survey results, and viewing survey data on the laptop.
The document provides instructions for various user management and survey building functions in 7 sections:
1. User management includes adding, deleting, and editing users, designations, and passwords.
2. Administrative hierarchy allows setting up divisions, districts, upazillas, unions, mouzas, and villages.
3. Survey builder covers creating, editing, and deleting sections, surveys, rounds, and survey sections. It also describes question types.
4. Data transfer explains uploading questions and downloading survey data to and from PDAs.
5. Data can be transferred to SPSS to create tables and populate data.
6. FAQs provide answers to common questions about survey creation and management.
CMMI (Capability Maturity Model Integration) is a process improvement framework that can be used to appraise an organization's process maturity. It addresses three areas: product/service development, service management, and product/service acquisition. CMMI models include staged and continuous representations. Staged provides a standard sequence of improvements while continuous allows a focus on important processes. There are five maturity levels from 2 (Managed) to 5 (Optimizing). Key process areas include requirements management, project monitoring and control, and organizational process definition. CMMI helps organizations improve processes, reduce costs and cycle times, and increase quality.
Reporting about Overview Summery of ISO-27000 Se.(ISMS)AHM Pervej Kabir
The document discusses the ISO 27000 series of standards for information security management systems (ISMS). It provides an overview of the main components of an ISMS, including developing security policies, performing risk management, implementing controls, conducting audits and reviews. The purpose is to provide adequate protection for organizational information assets and enable continual improvement of security processes. Key aspects covered are the main ISMS processes, developing the security policy, assessing risks, implementing controls, reviewing performance, and ensuring compliance with ISO 27001 requirements.
Embedded machine learning-based road conditions and driving behavior monitoringIJECEIAES
Car accident rates have increased in recent years, resulting in losses in human lives, properties, and other financial costs. An embedded machine learning-based system is developed to address this critical issue. The system can monitor road conditions, detect driving patterns, and identify aggressive driving behaviors. The system is based on neural networks trained on a comprehensive dataset of driving events, driving styles, and road conditions. The system effectively detects potential risks and helps mitigate the frequency and impact of accidents. The primary goal is to ensure the safety of drivers and vehicles. Collecting data involved gathering information on three key road events: normal street and normal drive, speed bumps, circular yellow speed bumps, and three aggressive driving actions: sudden start, sudden stop, and sudden entry. The gathered data is processed and analyzed using a machine learning system designed for limited power and memory devices. The developed system resulted in 91.9% accuracy, 93.6% precision, and 92% recall. The achieved inference time on an Arduino Nano 33 BLE Sense with a 32-bit CPU running at 64 MHz is 34 ms and requires 2.6 kB peak RAM and 139.9 kB program flash memory, making it suitable for resource-constrained embedded systems.
Harnessing WebAssembly for Real-time Stateless Streaming PipelinesChristina Lin
Traditionally, dealing with real-time data pipelines has involved significant overhead, even for straightforward tasks like data transformation or masking. However, in this talk, we’ll venture into the dynamic realm of WebAssembly (WASM) and discover how it can revolutionize the creation of stateless streaming pipelines within a Kafka (Redpanda) broker. These pipelines are adept at managing low-latency, high-data-volume scenarios.
A SYSTEMATIC RISK ASSESSMENT APPROACH FOR SECURING THE SMART IRRIGATION SYSTEMSIJNSA Journal
The smart irrigation system represents an innovative approach to optimize water usage in agricultural and landscaping practices. The integration of cutting-edge technologies, including sensors, actuators, and data analysis, empowers this system to provide accurate monitoring and control of irrigation processes by leveraging real-time environmental conditions. The main objective of a smart irrigation system is to optimize water efficiency, minimize expenses, and foster the adoption of sustainable water management methods. This paper conducts a systematic risk assessment by exploring the key components/assets and their functionalities in the smart irrigation system. The crucial role of sensors in gathering data on soil moisture, weather patterns, and plant well-being is emphasized in this system. These sensors enable intelligent decision-making in irrigation scheduling and water distribution, leading to enhanced water efficiency and sustainable water management practices. Actuators enable automated control of irrigation devices, ensuring precise and targeted water delivery to plants. Additionally, the paper addresses the potential threat and vulnerabilities associated with smart irrigation systems. It discusses limitations of the system, such as power constraints and computational capabilities, and calculates the potential security risks. The paper suggests possible risk treatment methods for effective secure system operation. In conclusion, the paper emphasizes the significant benefits of implementing smart irrigation systems, including improved water conservation, increased crop yield, and reduced environmental impact. Additionally, based on the security analysis conducted, the paper recommends the implementation of countermeasures and security approaches to address vulnerabilities and ensure the integrity and reliability of the system. By incorporating these measures, smart irrigation technology can revolutionize water management practices in agriculture, promoting sustainability, resource efficiency, and safeguarding against potential security threats.
Using recycled concrete aggregates (RCA) for pavements is crucial to achieving sustainability. Implementing RCA for new pavement can minimize carbon footprint, conserve natural resources, reduce harmful emissions, and lower life cycle costs. Compared to natural aggregate (NA), RCA pavement has fewer comprehensive studies and sustainability assessments.
Understanding Inductive Bias in Machine LearningSUTEJAS
This presentation explores the concept of inductive bias in machine learning. It explains how algorithms come with built-in assumptions and preferences that guide the learning process. You'll learn about the different types of inductive bias and how they can impact the performance and generalizability of machine learning models.
The presentation also covers the positive and negative aspects of inductive bias, along with strategies for mitigating potential drawbacks. We'll explore examples of how bias manifests in algorithms like neural networks and decision trees.
By understanding inductive bias, you can gain valuable insights into how machine learning models work and make informed decisions when building and deploying them.
Optimizing Gradle Builds - Gradle DPE Tour Berlin 2024Sinan KOZAK
Sinan from the Delivery Hero mobile infrastructure engineering team shares a deep dive into performance acceleration with Gradle build cache optimizations. Sinan shares their journey into solving complex build-cache problems that affect Gradle builds. By understanding the challenges and solutions found in our journey, we aim to demonstrate the possibilities for faster builds. The case study reveals how overlapping outputs and cache misconfigurations led to significant increases in build times, especially as the project scaled up with numerous modules using Paparazzi tests. The journey from diagnosing to defeating cache issues offers invaluable lessons on maintaining cache integrity without sacrificing functionality.
A review on techniques and modelling methodologies used for checking electrom...nooriasukmaningtyas
The proper function of the integrated circuit (IC) in an inhibiting electromagnetic environment has always been a serious concern throughout the decades of revolution in the world of electronics, from disjunct devices to today’s integrated circuit technology, where billions of transistors are combined on a single chip. The automotive industry and smart vehicles in particular, are confronting design issues such as being prone to electromagnetic interference (EMI). Electronic control devices calculate incorrect outputs because of EMI and sensors give misleading values which can prove fatal in case of automotives. In this paper, the authors have non exhaustively tried to review research work concerned with the investigation of EMI in ICs and prediction of this EMI using various modelling methodologies and measurement setups.
Redefining brain tumor segmentation: a cutting-edge convolutional neural netw...IJECEIAES
Medical image analysis has witnessed significant advancements with deep learning techniques. In the domain of brain tumor segmentation, the ability to
precisely delineate tumor boundaries from magnetic resonance imaging (MRI)
scans holds profound implications for diagnosis. This study presents an ensemble convolutional neural network (CNN) with transfer learning, integrating
the state-of-the-art Deeplabv3+ architecture with the ResNet18 backbone. The
model is rigorously trained and evaluated, exhibiting remarkable performance
metrics, including an impressive global accuracy of 99.286%, a high-class accuracy of 82.191%, a mean intersection over union (IoU) of 79.900%, a weighted
IoU of 98.620%, and a Boundary F1 (BF) score of 83.303%. Notably, a detailed comparative analysis with existing methods showcases the superiority of
our proposed model. These findings underscore the model’s competence in precise brain tumor localization, underscoring its potential to revolutionize medical
image analysis and enhance healthcare outcomes. This research paves the way
for future exploration and optimization of advanced CNN models in medical
imaging, emphasizing addressing false positives and resource efficiency.
ACEP Magazine edition 4th launched on 05.06.2024Rahul
This document provides information about the third edition of the magazine "Sthapatya" published by the Association of Civil Engineers (Practicing) Aurangabad. It includes messages from current and past presidents of ACEP, memories and photos from past ACEP events, information on life time achievement awards given by ACEP, and a technical article on concrete maintenance, repairs and strengthening. The document highlights activities of ACEP and provides a technical educational article for members.
Comparative analysis between traditional aquaponics and reconstructed aquapon...bijceesjournal
The aquaponic system of planting is a method that does not require soil usage. It is a method that only needs water, fish, lava rocks (a substitute for soil), and plants. Aquaponic systems are sustainable and environmentally friendly. Its use not only helps to plant in small spaces but also helps reduce artificial chemical use and minimizes excess water use, as aquaponics consumes 90% less water than soil-based gardening. The study applied a descriptive and experimental design to assess and compare conventional and reconstructed aquaponic methods for reproducing tomatoes. The researchers created an observation checklist to determine the significant factors of the study. The study aims to determine the significant difference between traditional aquaponics and reconstructed aquaponics systems propagating tomatoes in terms of height, weight, girth, and number of fruits. The reconstructed aquaponics system’s higher growth yield results in a much more nourished crop than the traditional aquaponics system. It is superior in its number of fruits, height, weight, and girth measurement. Moreover, the reconstructed aquaponics system is proven to eliminate all the hindrances present in the traditional aquaponics system, which are overcrowding of fish, algae growth, pest problems, contaminated water, and dead fish.
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