A tool and methodology to enumerate security functional requirements arising in the solution space is described. A proof of concept tool for use by security architects and security engineers is described. The tool facilitates use of community-developed security requirements packages, security functional requirements, threat model taxonomy including mitigations. A risk-based decision making process is facilitated. Tool outputs used for change checklist, new test requirements, system security plan, risk decision documentation, deferred controls, and inherited controls.
Technical hardware and software failures can compromise security if they are not addressed properly. Hardware failures may be due to known or unknown flaws and can cause unreliable service. Software bugs are also common due to the complexity of code. Examples of dangerous software failures include buffer overflows, SQL injection, and cross-site scripting. Developers must follow secure practices like minimizing privileges and implementing access controls to develop more secure software and systems.
Secure by Design - Security Design Principles for the Working ArchitectEoin Woods
As our world becomes digital, the systems we build must be secure by design. The security community has developed a well-understood set of principles used to build systems that are secure (or at least securable) by design, but this topic often isn’t included in the training of software developers. And when the principles are explained, they are often shrouded in the jargon of the security engineering community, so mainstream developers struggle to understand and apply them.
This talk explains why secure design matters and introduces 10 of the most important proven principles for designing secure systems, distilled from the wisdom of the security engineering community.
Integrating security into the development of an application or software is necessary to decrease its risk of susceptibility to attacks and exploits. Traditional methods of security testing were performed on a finished product. However, with the rise in the intensity and the number of attack vectors, it has become necessary for organizations to include it as a part of every phase of an SDLC.
This document discusses several secure design principles for software systems: the principle of least privilege, defense-in-depth, securing the weakeakest link, having fail-safe measures, being secure by default, keeping designs simple and usable. It provides examples for how to implement each principle and notes that security is a process, not a product, and following principles alone does not guarantee full security.
This document outlines several security frameworks that can be used to guide enterprise security architecture development. It discusses frameworks for information security management systems (ISO27000), enterprise architecture (Zachman, TOGAF), governance (COBIT, COSO), operational best practices (ITIL), and process improvement (Six Sigma, CMMI). The key aspects of a successful enterprise security architecture identified are strategic alignment with business needs, enabling business processes, enhancing existing processes, and ensuring security effectiveness through metrics and risk management.
AMI Security 101 - Smart Grid Security East 2011dma1965
The document outlines the agenda for an AMI security workshop, including introductions, an overview of AMI security challenges from both top-down and bottom-up perspectives, how utilities are managing security, vulnerability testing, lessons learned, and the road ahead. Presenters are from security companies and utilities to discuss topics like threat modeling, attack surfaces, software development lifecycles, penetration testing, and ongoing security processes.
This document discusses implementing a secure software development lifecycle (SDLC). It emphasizes building security into software from the start rather than adding it later. The summary is:
The document outlines a secure SDLC process involving defining security requirements, designing for security, implementing secure coding practices, testing software security, and ongoing security monitoring. It notes that software security is a shared responsibility and discusses challenges like team pushback and measuring security benefits. The document also presents a case study of a company that implemented a secure SDLC process to address client security issues and prevent future problems.
Technical hardware and software failures can compromise security if they are not addressed properly. Hardware failures may be due to known or unknown flaws and can cause unreliable service. Software bugs are also common due to the complexity of code. Examples of dangerous software failures include buffer overflows, SQL injection, and cross-site scripting. Developers must follow secure practices like minimizing privileges and implementing access controls to develop more secure software and systems.
Secure by Design - Security Design Principles for the Working ArchitectEoin Woods
As our world becomes digital, the systems we build must be secure by design. The security community has developed a well-understood set of principles used to build systems that are secure (or at least securable) by design, but this topic often isn’t included in the training of software developers. And when the principles are explained, they are often shrouded in the jargon of the security engineering community, so mainstream developers struggle to understand and apply them.
This talk explains why secure design matters and introduces 10 of the most important proven principles for designing secure systems, distilled from the wisdom of the security engineering community.
Integrating security into the development of an application or software is necessary to decrease its risk of susceptibility to attacks and exploits. Traditional methods of security testing were performed on a finished product. However, with the rise in the intensity and the number of attack vectors, it has become necessary for organizations to include it as a part of every phase of an SDLC.
This document discusses several secure design principles for software systems: the principle of least privilege, defense-in-depth, securing the weakeakest link, having fail-safe measures, being secure by default, keeping designs simple and usable. It provides examples for how to implement each principle and notes that security is a process, not a product, and following principles alone does not guarantee full security.
This document outlines several security frameworks that can be used to guide enterprise security architecture development. It discusses frameworks for information security management systems (ISO27000), enterprise architecture (Zachman, TOGAF), governance (COBIT, COSO), operational best practices (ITIL), and process improvement (Six Sigma, CMMI). The key aspects of a successful enterprise security architecture identified are strategic alignment with business needs, enabling business processes, enhancing existing processes, and ensuring security effectiveness through metrics and risk management.
AMI Security 101 - Smart Grid Security East 2011dma1965
The document outlines the agenda for an AMI security workshop, including introductions, an overview of AMI security challenges from both top-down and bottom-up perspectives, how utilities are managing security, vulnerability testing, lessons learned, and the road ahead. Presenters are from security companies and utilities to discuss topics like threat modeling, attack surfaces, software development lifecycles, penetration testing, and ongoing security processes.
This document discusses implementing a secure software development lifecycle (SDLC). It emphasizes building security into software from the start rather than adding it later. The summary is:
The document outlines a secure SDLC process involving defining security requirements, designing for security, implementing secure coding practices, testing software security, and ongoing security monitoring. It notes that software security is a shared responsibility and discusses challenges like team pushback and measuring security benefits. The document also presents a case study of a company that implemented a secure SDLC process to address client security issues and prevent future problems.
The document discusses the phases of the security systems development life cycle (SecSDLC). It describes the traditional SDLC phases of investigation, analysis, logical design, physical design, implementation, and maintenance/change. These same phases are then adapted for SecSDLC, with each phase focusing on identifying threats and creating controls. Additionally, the document introduces the concept of software assurance, which aims to include security planning across the entire SDLC process to develop more secure systems.
The document discusses the implementation phase of a security project life cycle. It explains that an organization's security blueprint must be translated into a detailed project plan that addresses leadership, budget, timelines, staffing needs, and organizational considerations. An effective project plan uses a work breakdown structure and considers financial, priority, scheduling, procurement, and change management factors. The project manager plays a key role in planning, supervising, and wrapping up the project successfully.
Embedded Systems Security: Building a More Secure DevicePriyanka Aash
The document discusses common security issues faced by embedded systems and recommendations for improving security. It identifies 12 common threats to embedded systems, such as supply chain attacks, physical access, reverse engineering, lack of secure configurations, and human errors. The document recommends building security functions into embedded systems from the start to defend against threats, understanding contract manufacturing processes, and ensuring host systems maintain control over security. It advises assessing risks and vulnerabilities based on the 12 threats and seeking external security reviews within 6 months.
ОЛЬГА АКСЬОНЕНКО «Безпечна розробка програмного забезпечення в 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 provides an overview of key concepts for application security design. It discusses the importance of incorporating security throughout the application development lifecycle. It outlines several security design aspects that should be considered, including authentication, authorization using roles, session management, and implementing a secure access layer. It also emphasizes the importance of security testing, code reviews, and conducting risk assessments and assurance testing prior to deployment. Finally, it discusses how to establish security guidelines and build a centralized security infrastructure with interoperable components to provide identity, authentication, authorization and other security services across applications in a standardized way.
This document provides information about security operations centers (SOCs). It discusses why organizations build security controls and capabilities like SOCs, which are designed to reduce risk, protect businesses, and move from reactive responses to proactive threat mitigation. The document defines a SOC as a skilled team that follows processes to manage threats and reduce security risk. It outlines the major responsibilities of a SOC, which include monitoring, analyzing, and responding to security events. It also notes that effective SOCs balance people, processes, and technology. The document provides details about building a SOC and considerations in each of these domains. It includes a sample job description for a SOC analyst role.
This document discusses principles of software design for information security. It summarizes key software design principles identified by Saltzer and Schroeder, including least privilege and separation of duties. It also outlines the National Institute of Standards and Technology's (NIST) approach to securing the software development lifecycle (SDLC), which involves integrating security early and conducting activities like risk assessments and testing at each phase. Finally, it describes various security roles in an organization, including the chief information security officer, security project team, data owners and custodians, and communities of interest.
This 2-day training course from Tonex focuses on applying cyber security principles to embedded systems. It covers fundamentals of both cyber security and embedded systems, analyzing vulnerabilities in embedded systems, and techniques for securely implementing and defending embedded systems. The course teaches how to examine, exploit, and harden real embedded devices and operating systems. It is designed for engineers, developers, and security professionals working with embedded technologies.
This document discusses security permissions in Primavera Contract Management (PCM) software and how custom reports can help audit and manage user security. It summarizes new reports created to identify issues such as mismatched access templates and project permissions. The reports link user and project assignments to access templates to find discrepancies. This allows administrators to ensure permissions are consistently applied according to templates. The document argues these reports satisfy requirements to understand which users have access to what projects and resources. It also explores applying the reporting concept to other areas of PCM data.
Cybersecurity Applied to Embedded Systems, Fundamentals of Embedded Systems a...Tonex
An embedded system is a microprocessor-based computer hardware system with software designed to perform dedicated functions, either as an independent system or as a part of a large system. The core is an integrated circuit designed to perform real-time operation calculations.
Embedded systems use tailored operating systems or language platforms, especially where a real-time operating environment must be provided. With higher-level chip functions (such as those in SoCs), designers increasingly decide that systems are usually fast enough and can withstand subtle changes in response time, so real-time methods are suitable. In these cases, a streamlined version of the Linux operating system is usually deployed
Ways to prevent cyber-attacks on embedded systems:
Expect firmware to be updated regularly
integration with third-party security management systems
Secure communication
Limit access to embedded systems to a need-to-use basis
Tonex offers "Cybersecurity Applied to Embedded Systems, Cybersecurity Training"
Learn about the basics of embedded systems and network security applications to illustrate unique vulnerabilities that are commonly exploited. Methods and techniques to consider cyber security measures in the entire system life cycle and acquisition process.
Learn About:
Risk assessment methodologies
Failure analysis and using defensive tools to mitigate cyber risk and vulnerabilities
Weapon systems, missiles, smart weapons
Network Enabled Weapons (NEW)
UAVs, Communications systems
Industrial control systems
medical devices, robotics, smart grid
SCADA, Intelligent Electronic Devices (IED), PLCs
Learning Objectives:
Examining how to fit cybersecurity in embedded systems
Fundamentals of cybersecurity
Fundamentals of Embedded Systems
Fundamentals of embedded system product design cycle, project management, design for production, V&V and O&M
Embedded Systems Security Requirements
Fundamentals of hardware and firmware analysis and design in embedded design
Vulnerabilities in embedded systems
Embedded hardware and firmware analysis
Foundation knowledge of cyber security threats, risks, mitigation strategies applied to embedded systems
And many more..
Audience
Product/process designers and engineers
Developers working with embedded systems
Information security professionals
Application developers
Course Outline
Cybersecurity 101
Introduction to Embedded Systems
Embedded System Vulnerability Analysis
Exploiting Real Time Operating Systems
Securing Embedded Systems Interfaces and Protocols
Cybersecurity Attacks and Best Mitigation Practices for Embedded Systems
Case Study and Workshop
Learn More:
https://www.tonex.com/cybersecurity-applied-to-embedded-systems-cybersecurity-training/
This document discusses physical security considerations for protecting computing facilities and information assets. It covers key physical access controls like walls, fences, locks, ID badges, alarms and electronic monitoring. Critical environment factors are also addressed, such as fire safety and ensuring proper temperature, humidity and power. The roles of general management, IT and information security professionals in implementing physical security measures are defined. Maintaining secure computer rooms and wiring closets is emphasized, as logical access controls can be easily defeated without strong accompanying physical security.
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 security requirements engineering and the SQUARE framework. It defines key terms like requirements, requirements engineering, and security requirements engineering. It then outlines the SQUARE framework which is a 9 step process for eliciting security requirements that includes agreeing on definitions, identifying goals, risk assessment, selecting techniques, and prioritizing requirements. Other frameworks are also briefly discussed and compared to SQUARE. Implementing security requirements engineering and SQUARE provides benefits like reducing risks and costs while protecting the business.
Building a Product Security Practice in a DevOps WorldArun Prabhakar
This document discusses building a product security practice in a DevOps world. It outlines key product security capabilities that enterprises should establish throughout the product lifecycle, including threat modeling, secure coding, software composition analysis, penetration testing, and continuous monitoring. It also discusses the importance of establishing governance around product security through defining roles, processes, and controls for different functions like business, operations, and security. The goal is to integrate software and product lifecycles in a coherent manner so that final products are secure without slowing down development.
William H. Linder has over 20 years of experience in IT security risk management, auditing, and compliance using frameworks such as COBIT and COSO. He has worked as an IT security risk manager and auditor for companies such as NBC Universal and Citigroup. Some of his responsibilities have included assessing risks, advising on control requirements, reviewing suppliers for compliance, and testing that controls are operating effectively. He also has experience in areas such as network security, disaster recovery, and application security assessments.
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 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.
This document provides guidance on conducting a DIY security assessment through summarizing background information on security life cycles and describing two assessment tools: ISS Internet Scanner and Nessus. It explains that assessments are an important part of the security life cycle. The security life cycle includes policies, assessment, design, deployment, management, and continual training. Assessments evaluate technical and non-technical areas to determine an organization's security posture. The document then gives examples of what to check during assessments and provides basic instructions for using ISS Scanner and Nessus to perform technical vulnerability assessments.
This document discusses security status reporting and outlines best practices for developing an effective security monitoring program. It recommends selecting critical business systems as the target environment and defining key performance indicators across areas like user access management, patching, and perimeter security. The document also provides guidance on setting baselines using standards, quantifying security status with CVSS scoring, understanding audience priorities, and building dashboards and reports that follow rules like only displaying relevant, meaningful data at an appropriate refresh rate for the intended audience. The overall aim is to facilitate effective decision making and reporting on security posture.
This document outlines a secure software development course. The course goals are to explain computer security needs and requirements, introduce security best practices, and present techniques for evaluating security solutions. It will be graded through exams, assignments, and a final exam. The course material will include a delivered textbook. The timeline shows the course content by week, covering topics like risk assessment, secure design patterns, threat modeling, and security testing. The document also provides the lecturer's contact information and defines key terms like information security risks and software security.
Security Culture from Concept to Maintenance: Secure Software Development Lif...Dilum Bandara
The document discusses implementing a Secure Software Development Lifecycle (SDLC) to help organizations build more secure software. It describes the key steps in the SDL process, including requirements, design, implementation, verification, release and response. Implementing an SDL can help minimize security issues and related costs through practices like threat modeling, secure coding and security testing throughout the development cycle. The challenges of adoption and ways to build a security culture are also addressed.
The document discusses the phases of the security systems development life cycle (SecSDLC). It describes the traditional SDLC phases of investigation, analysis, logical design, physical design, implementation, and maintenance/change. These same phases are then adapted for SecSDLC, with each phase focusing on identifying threats and creating controls. Additionally, the document introduces the concept of software assurance, which aims to include security planning across the entire SDLC process to develop more secure systems.
The document discusses the implementation phase of a security project life cycle. It explains that an organization's security blueprint must be translated into a detailed project plan that addresses leadership, budget, timelines, staffing needs, and organizational considerations. An effective project plan uses a work breakdown structure and considers financial, priority, scheduling, procurement, and change management factors. The project manager plays a key role in planning, supervising, and wrapping up the project successfully.
Embedded Systems Security: Building a More Secure DevicePriyanka Aash
The document discusses common security issues faced by embedded systems and recommendations for improving security. It identifies 12 common threats to embedded systems, such as supply chain attacks, physical access, reverse engineering, lack of secure configurations, and human errors. The document recommends building security functions into embedded systems from the start to defend against threats, understanding contract manufacturing processes, and ensuring host systems maintain control over security. It advises assessing risks and vulnerabilities based on the 12 threats and seeking external security reviews within 6 months.
ОЛЬГА АКСЬОНЕНКО «Безпечна розробка програмного забезпечення в 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 provides an overview of key concepts for application security design. It discusses the importance of incorporating security throughout the application development lifecycle. It outlines several security design aspects that should be considered, including authentication, authorization using roles, session management, and implementing a secure access layer. It also emphasizes the importance of security testing, code reviews, and conducting risk assessments and assurance testing prior to deployment. Finally, it discusses how to establish security guidelines and build a centralized security infrastructure with interoperable components to provide identity, authentication, authorization and other security services across applications in a standardized way.
This document provides information about security operations centers (SOCs). It discusses why organizations build security controls and capabilities like SOCs, which are designed to reduce risk, protect businesses, and move from reactive responses to proactive threat mitigation. The document defines a SOC as a skilled team that follows processes to manage threats and reduce security risk. It outlines the major responsibilities of a SOC, which include monitoring, analyzing, and responding to security events. It also notes that effective SOCs balance people, processes, and technology. The document provides details about building a SOC and considerations in each of these domains. It includes a sample job description for a SOC analyst role.
This document discusses principles of software design for information security. It summarizes key software design principles identified by Saltzer and Schroeder, including least privilege and separation of duties. It also outlines the National Institute of Standards and Technology's (NIST) approach to securing the software development lifecycle (SDLC), which involves integrating security early and conducting activities like risk assessments and testing at each phase. Finally, it describes various security roles in an organization, including the chief information security officer, security project team, data owners and custodians, and communities of interest.
This 2-day training course from Tonex focuses on applying cyber security principles to embedded systems. It covers fundamentals of both cyber security and embedded systems, analyzing vulnerabilities in embedded systems, and techniques for securely implementing and defending embedded systems. The course teaches how to examine, exploit, and harden real embedded devices and operating systems. It is designed for engineers, developers, and security professionals working with embedded technologies.
This document discusses security permissions in Primavera Contract Management (PCM) software and how custom reports can help audit and manage user security. It summarizes new reports created to identify issues such as mismatched access templates and project permissions. The reports link user and project assignments to access templates to find discrepancies. This allows administrators to ensure permissions are consistently applied according to templates. The document argues these reports satisfy requirements to understand which users have access to what projects and resources. It also explores applying the reporting concept to other areas of PCM data.
Cybersecurity Applied to Embedded Systems, Fundamentals of Embedded Systems a...Tonex
An embedded system is a microprocessor-based computer hardware system with software designed to perform dedicated functions, either as an independent system or as a part of a large system. The core is an integrated circuit designed to perform real-time operation calculations.
Embedded systems use tailored operating systems or language platforms, especially where a real-time operating environment must be provided. With higher-level chip functions (such as those in SoCs), designers increasingly decide that systems are usually fast enough and can withstand subtle changes in response time, so real-time methods are suitable. In these cases, a streamlined version of the Linux operating system is usually deployed
Ways to prevent cyber-attacks on embedded systems:
Expect firmware to be updated regularly
integration with third-party security management systems
Secure communication
Limit access to embedded systems to a need-to-use basis
Tonex offers "Cybersecurity Applied to Embedded Systems, Cybersecurity Training"
Learn about the basics of embedded systems and network security applications to illustrate unique vulnerabilities that are commonly exploited. Methods and techniques to consider cyber security measures in the entire system life cycle and acquisition process.
Learn About:
Risk assessment methodologies
Failure analysis and using defensive tools to mitigate cyber risk and vulnerabilities
Weapon systems, missiles, smart weapons
Network Enabled Weapons (NEW)
UAVs, Communications systems
Industrial control systems
medical devices, robotics, smart grid
SCADA, Intelligent Electronic Devices (IED), PLCs
Learning Objectives:
Examining how to fit cybersecurity in embedded systems
Fundamentals of cybersecurity
Fundamentals of Embedded Systems
Fundamentals of embedded system product design cycle, project management, design for production, V&V and O&M
Embedded Systems Security Requirements
Fundamentals of hardware and firmware analysis and design in embedded design
Vulnerabilities in embedded systems
Embedded hardware and firmware analysis
Foundation knowledge of cyber security threats, risks, mitigation strategies applied to embedded systems
And many more..
Audience
Product/process designers and engineers
Developers working with embedded systems
Information security professionals
Application developers
Course Outline
Cybersecurity 101
Introduction to Embedded Systems
Embedded System Vulnerability Analysis
Exploiting Real Time Operating Systems
Securing Embedded Systems Interfaces and Protocols
Cybersecurity Attacks and Best Mitigation Practices for Embedded Systems
Case Study and Workshop
Learn More:
https://www.tonex.com/cybersecurity-applied-to-embedded-systems-cybersecurity-training/
This document discusses physical security considerations for protecting computing facilities and information assets. It covers key physical access controls like walls, fences, locks, ID badges, alarms and electronic monitoring. Critical environment factors are also addressed, such as fire safety and ensuring proper temperature, humidity and power. The roles of general management, IT and information security professionals in implementing physical security measures are defined. Maintaining secure computer rooms and wiring closets is emphasized, as logical access controls can be easily defeated without strong accompanying physical security.
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 security requirements engineering and the SQUARE framework. It defines key terms like requirements, requirements engineering, and security requirements engineering. It then outlines the SQUARE framework which is a 9 step process for eliciting security requirements that includes agreeing on definitions, identifying goals, risk assessment, selecting techniques, and prioritizing requirements. Other frameworks are also briefly discussed and compared to SQUARE. Implementing security requirements engineering and SQUARE provides benefits like reducing risks and costs while protecting the business.
Building a Product Security Practice in a DevOps WorldArun Prabhakar
This document discusses building a product security practice in a DevOps world. It outlines key product security capabilities that enterprises should establish throughout the product lifecycle, including threat modeling, secure coding, software composition analysis, penetration testing, and continuous monitoring. It also discusses the importance of establishing governance around product security through defining roles, processes, and controls for different functions like business, operations, and security. The goal is to integrate software and product lifecycles in a coherent manner so that final products are secure without slowing down development.
William H. Linder has over 20 years of experience in IT security risk management, auditing, and compliance using frameworks such as COBIT and COSO. He has worked as an IT security risk manager and auditor for companies such as NBC Universal and Citigroup. Some of his responsibilities have included assessing risks, advising on control requirements, reviewing suppliers for compliance, and testing that controls are operating effectively. He also has experience in areas such as network security, disaster recovery, and application security assessments.
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 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.
This document provides guidance on conducting a DIY security assessment through summarizing background information on security life cycles and describing two assessment tools: ISS Internet Scanner and Nessus. It explains that assessments are an important part of the security life cycle. The security life cycle includes policies, assessment, design, deployment, management, and continual training. Assessments evaluate technical and non-technical areas to determine an organization's security posture. The document then gives examples of what to check during assessments and provides basic instructions for using ISS Scanner and Nessus to perform technical vulnerability assessments.
This document discusses security status reporting and outlines best practices for developing an effective security monitoring program. It recommends selecting critical business systems as the target environment and defining key performance indicators across areas like user access management, patching, and perimeter security. The document also provides guidance on setting baselines using standards, quantifying security status with CVSS scoring, understanding audience priorities, and building dashboards and reports that follow rules like only displaying relevant, meaningful data at an appropriate refresh rate for the intended audience. The overall aim is to facilitate effective decision making and reporting on security posture.
This document outlines a secure software development course. The course goals are to explain computer security needs and requirements, introduce security best practices, and present techniques for evaluating security solutions. It will be graded through exams, assignments, and a final exam. The course material will include a delivered textbook. The timeline shows the course content by week, covering topics like risk assessment, secure design patterns, threat modeling, and security testing. The document also provides the lecturer's contact information and defines key terms like information security risks and software security.
Security Culture from Concept to Maintenance: Secure Software Development Lif...Dilum Bandara
The document discusses implementing a Secure Software Development Lifecycle (SDLC) to help organizations build more secure software. It describes the key steps in the SDL process, including requirements, design, implementation, verification, release and response. Implementing an SDL can help minimize security issues and related costs through practices like threat modeling, secure coding and security testing throughout the development cycle. The challenges of adoption and ways to build a security culture are also addressed.
4_25655_SE731_2020_1__2_1_Lecture 1 - Course Outline and Secure SDLC.pptgealehegn
This document provides an overview of a course on security in software engineering. The course goals are to explain the need for computer security, how to meet security requirements using established techniques, and how to address risks through novel technologies. The course introduces security best practices and techniques for evaluating security solutions. It is taught by Dr. Nada Hany Sherief and provides contact information. The grading system and course timeline are outlined. Course material includes a textbook, lectures, and assignments available online. The document concludes with definitions from the glossary.
A New Security Management Approach for Agile EnvironmentsPECB
The traditional approach for security management fails in agile development projects. We summarize the cause of this failure and propose a new Agile Security Engagement Model (ASEM) to solve the issues. This model is risk-driven, supportive and robust. It embraces important innovations, such as a security services catalogue and continuous monitoring. This way of working helps organizations to properly address information security in agile environments.
Main points that have been covered are:
• Four false assumptions that make the traditional security approach fail
• ‘Feet in the mud’ with the Agile Security Engagement Model (ASEM)
• Explanation of the innovations in this Agile Security approach
Presenter:
Pascal de Koning is qualified as Information Security professional. He has the wide experience as a consultant and fills in the role of the security officer at various companies. Pascal is an active member of the Security Forum of The Open Group.
Link of the recorded session published on YouTube: https://youtu.be/08Se5Ta65v8
The document discusses challenges with traditional security management approaches in agile development environments. It proposes a new Agile Security Engagement Model (ASEM) to address these challenges. ASEM involves making security experts part of the development team, adding security-related user stories, providing security building blocks through a service catalog, implementing detailed security policies when needed, classifying security measures to automate decisions, conducting daily automated security tests, and establishing continuous independent monitoring of the development process. The goal of ASEM is to take a hands-on approach to security and provide reusable security services, patterns and continuous monitoring to help address risks in an agile context where not all can be fully addressed.
Fundamental Best Practices in Secure IoT Product DevelopmentMark Szewczul, CISSP
The document provides guidance on best practices for secure IoT product development. It discusses the top 5 security considerations which include implementing secure firmware updates, authentication and encryption on product interfaces, independent security assessments, securing companion mobile apps/gateways, and implementing a secure root of trust. It also highlights lessons learned from privacy and security issues with IoT products like baby monitors, fitness trackers, medical devices, drones, critical infrastructure systems, and autonomous vehicles. Recommendations provided include adopting a security-by-design approach, threat modeling products, implementing secure development processes, and incorporating privacy principles.
This document provides an overview of secure software engineering and the role of security testers. It discusses how security should be considered a core feature rather than an afterthought in the development process. The document outlines Microsoft's Security Development Lifecycle (SDL) as a comprehensive software process model that embeds security activities throughout requirements, design, implementation, verification and evolution. It describes how threat modeling can be used to identify potential threats and vulnerabilities. Finally, it discusses the security tester's role in building test plans from threat models, testing component interfaces using data mutation techniques, and adopting a "hacker's mindset" to find security issues.
We are all aware of the current risks when developing a connected product, especially with vehicles since much is at stake both from an information and safety perspective. In this workshop, we will learn how to build Security requirements, architect, design, test and produce Safety and Security critical components using a methodology that works in harmony both with Engineering and Security
This document summarizes a presentation given by Craig Heilmann of IBM Security Services at the S4 ICS Security Conference in January 2015. The presentation discussed accelerating cyber security for operational technology (OT) using a case study. The case study involved a large manufacturer that wanted to transform its security operations over 5 years but faced constraints. The solution was to focus first on operations using an "elastic and agile" model with processes, operations, and technology improvements to quickly detect, respond, and disrupt attacks. This included enterprise-wide password changes and a security program framework to continuously adapt and mature capabilities over time. Cost modeling was also introduced to better plan and rationalize security spending.
The document discusses organizing software security knowledge into a unified knowledge architecture to facilitate sharing expertise. It proposes categorizing knowledge into prescriptive (principles, guidelines, rules), diagnostic (vulnerabilities, exploits, attack patterns), and historical. Examples of a principle and rule are provided. The goal is to compile knowledge from experts and make it widely accessible through a portal to help more practitioners given the limited number of experts available for apprenticeship. Feedback is sought to refine and validate the knowledge architecture.
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
This presentation by Christopher Grayson covers some lessons learned as a security professional that has made his way into software engineering full time.
The document discusses software development security and the software development life cycle (SDLC). It covers integrating security into each phase of the SDLC, including initiation, development, implementation, operation, and disposal. Different SDLC methodologies are described, such as waterfall, agile, DevOps, and DevSecOps. Maturity models for software security and the role of integrated product teams are also summarized.
7.2-0-D8-October2021 (Software Development Security).pptxroongrus
The document discusses software development security and the software development life cycle (SDLC). It covers topics like integrating security into the SDLC, applying security controls in development ecosystems, assessing software security effectiveness, and defining secure coding guidelines. It also provides overviews of different SDLC methodologies like waterfall, agile, DevOps, and DevSecOps as well as maturity models like CMM and SAMM.
The document introduces the secure boot pattern, which addresses ensuring the integrity of the software stack loaded on a platform. The pattern uses a chain of trust where each boot stage verifies the integrity of the next stage using cryptographic methods. The root of trust is a first module protected by hardware that verifies the initial integrity. The pattern provides security benefits while introducing complexity and overhead. Variants include authenticated boot, which detects instead of preventing integrity violations.
A Warrior's Journey: Building a Global AppSec Program - OWASP Global AppSec 2020Brian Levine
"Adapt what is useful, reject what is useless, and add what is specifically your own." -Bruce Lee
Full transcript is here, https://www.linkedin.com/pulse/warriors-journey-building-global-appsec-program-owasp-brian-levine
This talk covers critical foundations for building a scalable Application Security Program.
Drawing on warrior-tested strategies and assurance frameworks such as OWASP SAMM and BSIMM, this session gives actionable guidance on building and advancing a global application security program.
Whether you are starting a fledgling security journey or managing a mature SSDLC, these foundational elements are core for achieving continuous security at scale.
Brian Levine is Senior Director of Product Security for Axway, an enterprise software company, delivering product solutions and cloud services to global Fortune 500 enterprises and government customers.
If you were tasked with building a security program, imagine it's day 1 in your new role as an application security manager, which playbook would you use? There’s an Alphabet Soup of standards to choose from, you have ISO, SOC2, OWASP, NIST, BSIMM, PCI, CSA, and on and on.
Is there a script you could follow? And which set of frameworks would you use to get started in the right direction?
My talk today is going to draw on this quote and the wisdoms of the martial arts master and philosopher Bruce Lee. Adapt what is useful, reject what is useless, and add what is specifically your own. So, in that spirit I’m going to draw on my own experience with some of these frameworks and guidelines and cover the core foundational components that I feel have led to my success and I hope will help you get started.
What I’m hoping you’ll get out of this talk are some strategies and tactics that you can use to develop and improve your program.
[Slide 6] What we’re going to cover in these three core areas. We’ll focus on establishing a security Culture, we’ll look at developing and scaling security Processes and we’ll look at Governance for ensuring visibility and executive accountability
The security practitioner's role is changing significantly. Trends like mobile, cloud, DevOps, and Zero Trust are creating new roles and erasing others. This presentation navigates these changes and makes some recommendations for folks wanting to keep up with the curve.
Information security aims to balance information risks and controls. It began with early computer security focused on physical threats. A successful security approach uses multiple layers including physical, personal, operations, communications, network, and information security. Managing information security requires a structured methodology similar to implementing a major system, such as the Security Systems Development Life Cycle.
01Introduction to Information Security.pptit160320737038
A distributed system is a collection of computer programs that utilize computational resources across multiple, separate computation nodes to achieve a common, shared goal. Distributed systems aim to remove bottlenecks or central points of failure from a system.
Similar to Enumerating software security design flaws throughout the SSDLC (20)
What is Augmented Reality Image Trackingpavan998932
Augmented Reality (AR) Image Tracking is a technology that enables AR applications to recognize and track images in the real world, overlaying digital content onto them. This enhances the user's interaction with their environment by providing additional information and interactive elements directly tied to physical images.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Why Mobile App Regression Testing is Critical for Sustained Success_ A Detail...kalichargn70th171
A dynamic process unfolds in the intricate realm of software development, dedicated to crafting and sustaining products that effortlessly address user needs. Amidst vital stages like market analysis and requirement assessments, the heart of software development lies in the meticulous creation and upkeep of source code. Code alterations are inherent, challenging code quality, particularly under stringent deadlines.
OpenMetadata Community Meeting - 5th June 2024OpenMetadata
The OpenMetadata Community Meeting was held on June 5th, 2024. In this meeting, we discussed about the data quality capabilities that are integrated with the Incident Manager, providing a complete solution to handle your data observability needs. Watch the end-to-end demo of the data quality features.
* How to run your own data quality framework
* What is the performance impact of running data quality frameworks
* How to run the test cases in your own ETL pipelines
* How the Incident Manager is integrated
* Get notified with alerts when test cases fail
Watch the meeting recording here - https://www.youtube.com/watch?v=UbNOje0kf6E
Neo4j - Product Vision and Knowledge Graphs - GraphSummit ParisNeo4j
Dr. Jesús Barrasa, Head of Solutions Architecture for EMEA, Neo4j
Découvrez les dernières innovations de Neo4j, et notamment les dernières intégrations cloud et les améliorations produits qui font de Neo4j un choix essentiel pour les développeurs qui créent des applications avec des données interconnectées et de l’IA générative.
DDS Security Version 1.2 was adopted in 2024. This revision strengthens support for long runnings systems adding new cryptographic algorithms, certificate revocation, and hardness against DoS attacks.
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteGoogle
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
👉👉 Click Here To Get More Info 👇👇
https://sumonreview.com/ai-pilot-review/
AI Pilot Review: Key Features
✅Deploy AI expert bots in Any Niche With Just A Click
✅With one keyword, generate complete funnels, websites, landing pages, and more.
✅More than 85 AI features are included in the AI pilot.
✅No setup or configuration; use your voice (like Siri) to do whatever you want.
✅You Can Use AI Pilot To Create your version of AI Pilot And Charge People For It…
✅ZERO Manual Work With AI Pilot. Never write, Design, Or Code Again.
✅ZERO Limits On Features Or Usages
✅Use Our AI-powered Traffic To Get Hundreds Of Customers
✅No Complicated Setup: Get Up And Running In 2 Minutes
✅99.99% Up-Time Guaranteed
✅30 Days Money-Back Guarantee
✅ZERO Upfront Cost
See My Other Reviews Article:
(1) TubeTrivia AI Review: https://sumonreview.com/tubetrivia-ai-review
(2) SocioWave Review: https://sumonreview.com/sociowave-review
(3) AI Partner & Profit Review: https://sumonreview.com/ai-partner-profit-review
(4) AI Ebook Suite Review: https://sumonreview.com/ai-ebook-suite-review
WhatsApp offers simple, reliable, and private messaging and calling services for free worldwide. With end-to-end encryption, your personal messages and calls are secure, ensuring only you and the recipient can access them. Enjoy voice and video calls to stay connected with loved ones or colleagues. Express yourself using stickers, GIFs, or by sharing moments on Status. WhatsApp Business enables global customer outreach, facilitating sales growth and relationship building through showcasing products and services. Stay connected effortlessly with group chats for planning outings with friends or staying updated on family conversations.
Launch Your Streaming Platforms in MinutesRoshan Dwivedi
The claim of launching a streaming platform in minutes might be a bit of an exaggeration, but there are services that can significantly streamline the process. Here's a breakdown:
Pros of Speedy Streaming Platform Launch Services:
No coding required: These services often use drag-and-drop interfaces or pre-built templates, eliminating the need for programming knowledge.
Faster setup: Compared to building from scratch, these platforms can get you up and running much quicker.
All-in-one solutions: Many services offer features like content management systems (CMS), video players, and monetization tools, reducing the need for multiple integrations.
Things to Consider:
Limited customization: These platforms may offer less flexibility in design and functionality compared to custom-built solutions.
Scalability: As your audience grows, you might need to upgrade to a more robust platform or encounter limitations with the "quick launch" option.
Features: Carefully evaluate which features are included and if they meet your specific needs (e.g., live streaming, subscription options).
Examples of Services for Launching Streaming Platforms:
Muvi [muvi com]
Uscreen [usencreen tv]
Alternatives to Consider:
Existing Streaming platforms: Platforms like YouTube or Twitch might be suitable for basic streaming needs, though monetization options might be limited.
Custom Development: While more time-consuming, custom development offers the most control and flexibility for your platform.
Overall, launching a streaming platform in minutes might not be entirely realistic, but these services can significantly speed up the process compared to building from scratch. Carefully consider your needs and budget when choosing the best option for you.
Mobile app Development Services | Drona InfotechDrona Infotech
Drona Infotech is one of the Best Mobile App Development Company In Noida Maintenance and ongoing support. mobile app development Services can help you maintain and support your app after it has been launched. This includes fixing bugs, adding new features, and keeping your app up-to-date with the latest
Visit Us For :
May Marketo Masterclass, London MUG May 22 2024.pdfAdele Miller
Can't make Adobe Summit in Vegas? No sweat because the EMEA Marketo Engage Champions are coming to London to share their Summit sessions, insights and more!
This is a MUG with a twist you don't want to miss.
Utilocate offers a comprehensive solution for locate ticket management by automating and streamlining the entire process. By integrating with Geospatial Information Systems (GIS), it provides accurate mapping and visualization of utility locations, enhancing decision-making and reducing the risk of errors. The system's advanced data analytics tools help identify trends, predict potential issues, and optimize resource allocation, making the locate ticket management process smarter and more efficient. Additionally, automated ticket management ensures consistency and reduces human error, while real-time notifications keep all relevant personnel informed and ready to respond promptly.
The system's ability to streamline workflows and automate ticket routing significantly reduces the time taken to process each ticket, making the process faster and more efficient. Mobile access allows field technicians to update ticket information on the go, ensuring that the latest information is always available and accelerating the locate process. Overall, Utilocate not only enhances the efficiency and accuracy of locate ticket management but also improves safety by minimizing the risk of utility damage through precise and timely locates.
SOCRadar's Aviation Industry Q1 Incident Report is out now!
The aviation industry has always been a prime target for cybercriminals due to its critical infrastructure and high stakes. In the first quarter of 2024, the sector faced an alarming surge in cybersecurity threats, revealing its vulnerabilities and the relentless sophistication of cyber attackers.
SOCRadar’s Aviation Industry, Quarterly Incident Report, provides an in-depth analysis of these threats, detected and examined through our extensive monitoring of hacker forums, Telegram channels, and dark web platforms.
Introducing Crescat - Event Management Software for Venues, Festivals and Eve...Crescat
Crescat is industry-trusted event management software, built by event professionals for event professionals. Founded in 2017, we have three key products tailored for the live event industry.
Crescat Event for concert promoters and event agencies. Crescat Venue for music venues, conference centers, wedding venues, concert halls and more. And Crescat Festival for festivals, conferences and complex events.
With a wide range of popular features such as event scheduling, shift management, volunteer and crew coordination, artist booking and much more, Crescat is designed for customisation and ease-of-use.
Over 125,000 events have been planned in Crescat and with hundreds of customers of all shapes and sizes, from boutique event agencies through to international concert promoters, Crescat is rigged for success. What's more, we highly value feedback from our users and we are constantly improving our software with updates, new features and improvements.
If you plan events, run a venue or produce festivals and you're looking for ways to make your life easier, then we have a solution for you. Try our software for free or schedule a no-obligation demo with one of our product specialists today at crescat.io
Transform Your Communication with Cloud-Based IVR SolutionsTheSMSPoint
Discover the power of Cloud-Based IVR Solutions to streamline communication processes. Embrace scalability and cost-efficiency while enhancing customer experiences with features like automated call routing and voice recognition. Accessible from anywhere, these solutions integrate seamlessly with existing systems, providing real-time analytics for continuous improvement. Revolutionize your communication strategy today with Cloud-Based IVR Solutions. Learn more at: https://thesmspoint.com/channel/cloud-telephony
GraphSummit Paris - The art of the possible with Graph TechnologyNeo4j
Sudhir Hasbe, Chief Product Officer, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
2. Speaker Background
• Security architect/engineer with a history of electronics engineering,
programming, and configuration management.
• First computer was a wire-wrap Z80 board programmed in assembly.
• Nowadays, seeks to build security in by coming up with new and
different ways of doing things.
• Long list of security certifications including:
• Stanford University, Advanced Computer Security Professional
• Certified Secure Software Lifecycle Professional (CSSLP)
• CISSP-ISSAP (Information Systems Security Architecture
Professional)
2
3. Acknowledgments
• Mike Willis has helped by creating the prototype Ruby application
code for the Qt-based GUI that uses neo4j-core to interface to the
Neo4j database
• An un-named esteemed Informatics professor who highly
recommended we use Neo4j
3
4. Theory
By employing the methodology/tool described here, we should:
• Be able to establish order where there is currently chaos regarding
the identification and satisfaction of security requirements
• Not only in the solution space—but throughout the Secure Software
Development Life Cycle (SSDLC) as well.
4
5. This is a Work In Progress
• Will provide background information
• Reason for creating – lack of security engineering formal discipline
• Initial Proof of Concept, Prototype
• Specify requirements for an application security requirements
modeling tool
• Mock-ups for screens
• Progress to-date on screens
• Progress on graph database backend
• Path forward to include community developed requirements and
threat libraries
• Low level technical security requirements/controls—not at code level
(almost, though) 5
6. This Tool Will Go from This …
• Add web user TLS connection during the architecture and design
process
OR
• Add web user TLS connection to mitigated Man-in-the-Middle (MITM)
threat modeling finding
6
7. To This … Summary of Requirements for TLS Connection
- Key distribution - Behavior when security attributes expire
- Secure back-end connections - Define & maintain roles
- Confidentiality, integrity & availability - Associate users with roles
- Replay protection - Provide reliable time stamps
- Error recovery - Scope session security attributes
- Authentication failure behavior - Limit concurrent sessions
- Permitted pre-authentication actions - Inactivity lock/unlock behavior
- Prevent & detect authentication forgery - Inactivity session termination
- Prevent & detect use of copied
authentication data
- Segmentation of different types of
communication (e.g., user vs. admin)
- Different privileges of local vs. remote
users
- Specify which endpoints initiate
connection
- Limit authentication feedback - Deny session based on attributes
- Control who can change security
attributes
- Force re-authentication when needed
- Key destruction 7
8. What Makes it Different &Who Would Use It
• This tool would facilitate capture of detailed architecture and design
requirements during the solution phase of a project, and enable
testing and documentation of those requirements
• Facilitate enumeration of requirements using a user configurable
library of hierarchical security requirements packages, and
standardized Threat Model taxonomy with mitigating controls.
• The requirements library and taxonomy could be community
developed
• Initially, security architects / engineers and consultants would use the
tool
• Ultimately, it should be simple enough for developers to use
8
9. Brief History of Security Engineering
• Once upon a time there was a lot of interest in Security Engineering
as a scientific discipline even in the commercial sector
• Then, COTS products began to evolve and they filled a gap—whether
completely or not
• Build vs. Buy cost trade-off considerations
• Business pushed back and dropped support for applying full Security
Engineering (except perhaps with Defense security)
• As a result, at least in non-research circles, we do the best we can
with the COTS products we are given – leaving gaps that may or may
not be addressed
• Security Engineering as a formal discipline does not exist
9
10. Requirements & Security
• Operating Environment / Concept of Operations
• Business Requirements
• Security Functional Requirements
• (Security) Non-Functional Requirements
• Drivers:
• Users
• Law/Regulations
• Organizational Policy
• Risk Assessments are performed inconsistently, at varying levels of
depth – or not at all
• Not everyone includes misuse and abuse cases
10
11. Solution Space Security Engineering Challenges
• Code has vulnerabilities originating from various sources
• About 1/3rd of all Common Weaknesses and Enumerations (CWEs) fall
into the category of Design Errors – This is significant
• Nonfunctional security requirements often do not get translated into
real/documented technical security design features, or controls
• Security design features have their own dependencies
• Threat Modeling approaches are often subjective and may or may not
uncover the above
• Relevant technical security controls often do not get considered in
Unit, Integration or QA test cases
11
12. Common Criteria
Security Functional Requirements
• Common Criteria is an international framework for certifying that
products are secure within a specific environmental context
• This talk has nothing to do with certifying products
• It has a detailed list of 134 Security Functional Requirements
• These requirements have dependencies on each other
• We are repurposing these requirements as a starting point for a
standardized security requirements library
12
13. Uncommon Body of Knowledge – Modeling Research
• We have had code generation from CASE tool models for decades, yet
today only 4% of code is automatically generated using these tools
• UMLsec has been around for at least 10 years, but requires significant
effort to utilize properly (XML with security expressed in equation
form), and coverage is limited
• A significant body of research exists for reusing the Common Criteria
Security Functional Requirements (CC SFRs)
• There has been work to integrate the CC SFRs and UMLsec
• Security patterns and pattern languages exist at various levels of
abstraction for architecture as well as for design. Use is limited to very
large organizations
• There is a distinct lack of integration & automation between modeling
tools & techniques used at various stages of the development lifecycle
13
14. Modeling Capabilities vs. OWASP Top 10
Source: Why Model Driven Security will not secure your Web Application Hochreiner, et al. Journal of Wireless
Mobile Networks, Ubiquitous Computing, and Dependable Applications, volume: 5, number: 3, pp. 44-62 14
15. Current State of Insecurity Engineering
• There is no commonly accepted complete standard security
engineering maturity model (merge SSE-CMM, now ISO/IEC
21827:2008, & BSIMM). Then there’s NIST SP 800-160 (Draft)
• Misuse/abuse cases not always specified, not complete in coverage
• Security pattern modeling is still early-stage and there are few, if any,
open source UML repositories (do you know of any?)
• Security engineering modeling needs to flow from architecture &
design pattern models in order to achieve significant adoption
• There is little SDLC end-to-end modeling integration even for systems
engineering tools… everything is market-driven…
• Different tools/methods exist in various stages of maturity
• A number of tools/methods are inexact, incomplete, and must be
applied in a subjective manner to be effective (e.g., Threat Modeling)
• Threat Modeling is a Best Practice that is not widely implemented 15
16. Architect / Design / Solution Space Activities
• Design of security functionality and features to implement non-
functional security requirements
• A Security Architect &/or Engineer should be on board to allocate &
develop technical security controls for all requirements
• Control requirements should accompany security architecture and
design patterns
• Technical security requirements that are addressed need to be
captured for testing and documentation purposes
• Need a formal discipline for the security engineer to follow
• Security engineering methods, which must be well defined, need to
be applied consistently and completely – there needs to be a formal
discipline
16
17. Unit, Integration & QA Testing of Security
Testing should have the following inputs for test planning and test case
design:
• Requirements
• Need to be complete—including requirements enumerated during
the architecture and design phase
• We cannot rely on the Requirements document to provide
everything we need
• Security Architecture & Design Patterns
• Threat Model
• Security Assessment
These should always be included, so we do not have gaps
17
18. How to Establish Order from Chaos
• Identify key factors
• Identify those which are highly variable
• Characterize (describe) these highly variable key factors as well as
contributing variables
• Control the factors that affect variability
18
19. Variables to Capture, Characterize & Control
• Identify what information assets you are trying to protect
• Technical security controls flowing from Requirements
• Allocation of design to technical security controls, including nonfunctional
security requirements (solution space)
• Design phase Threat Modeling and resulting mitigations (lead to new
technical security controls) (solution space)
• Mitigations from Security/Risk Assessments (from various SSDLC phases)
19
20. Variables to Capture, Characterize & Control
(cont’d)
• Security requirements dependencies
• Risk-Benefit Analysis of each security requirement
• Which technical security controls should be implemented?
• Which technical security controls are being, or should be, tested?
Doing so will facilitate determining which technical security controls are
missing from our design in a reproducible manner
20
21. Reusing Common Criteria (CC)
Security Functional Requirements (SFRs)
• There is an established body of literature pertaining to the reuse of
Common Criteria Security Functional Requirements. This is a good
starting point
• Dependencies exist between different SFRs, so this helps us expand
what we think our controls are into something more comprehensive
• But where do we start?
• Dan Wu doctoral thesis SFR Reusable Packages. Security Functional
Requirements Analysis for Developing Secure Software, Doctoral
Thesis, Dan Wu, May 2007
• Security Tactics and Goals. Preschern, C. 2012. Catalog of Security
Tactics linked to Common Criteria Requirements.
21
22. TLS Use Case
• From this point forward, we will provide examples of security
functional requirements relating to implementation of Transport
Layer Security (TLS)
22
28. CC SFR Dependency Tables (example)
28
Source: Common Criteria for Information Technology Security Evaluation (CC v3.1), Revision 2, Part 2:
Security functional components.
29. STRIDE Based Threat Modeling
29Source: Adam Shostack. Threat Modeling: Designing for Security. John Wiley & Sons, Inc., 2014
30. Spoof Client Threat Tree (Partial)
30
Source: Adam Shostack. Threat Modeling: Designing for Security. John Wiley & Sons, Inc., 2014
(B-1)
31. Codifying Standard Threat Model (Example)
Spoof.Client
Spoof.Client.AuthenticationUI
Spoof.Client.AuthenticationUI.LocalLogin
Spoof.Client.AuthenticationUI.PrivilegedAccess
Spoof.Client.AuthenticationUI.RemoteSpoof
Spoof.Client.BackupAuthentication
Spoof.Client.BackupAuthentication.ChainedAuthentication
Spoof.Client.BackupAuthentication.InformationDisclosure
Spoof.Client.BackupAuthentication.KnowledgeBasedAuthentication
Spoof.Client.InsufficientAuthentication
Spoof.Client.InsufficientAuthentication.DowngradeAuthentication
31
Spoof.Client.InsufficientAuthentication.NullCreds
Spoof.Client.InsufficientAuthentication.PredicatbleCreds
Spoof.Client.NoAuthentication
Spoof.Client.ObtainCredentials
Spoof.Client.ObtainCredentials.ChangeManagement
Spoof.Client.ObtainCredentials.FederationIssues
Spoof.Client.ObtainCredentials.Storage
Spoof.Client.ObtainCredentials.Storage.at3rdParty
Spoof.Client.ObtainCredentials.Storage.atClient
Spoof.Client.ObtainCredentials.Storage.atKDC
Spoof.Client.ObtainCredentials.Storage.atServer
Spoof.Client.ObtainCredentials.Transit
Spoof.Client.OtherAuthenticationAttack
Derived from Source: Adam Shostack. Threat Modeling: Designing for Security. John Wiley & Sons, Inc., 2014
32. Standardizing Threat Mitigations (Example)
32Source: Adam Shostack. Threat Modeling: Designing for Security. John Wiley & Sons, Inc., 2014
(B-1)
33. Standardized Tool-Based Threat Modeling
• Context needed in certain cases (External Entity, Process, Data Flow,
Data Store, Security Requirements Package selection & options)
• Tool should know what type of connection it is based on context (e.g.,
TLS for a web app)
• Define a standardized taxonomy (e.g., using Threat Trees), codify
them, along with mitigations based on context
• Define your model – start somewhere and build from there
• Always ensure all attacks are accounted for when you are performing
your threat modeling
33
34. Proof of Concept
• Very rough shell script version
• Threat Modeling – concern about a web application user login and
man-in-the-middle attack -- recommended mitigation of SSL (TLS)
• Does not include navigation via Threat Tree to select mitigation
• User authentication, confidentiality of password and integrity of data
are the applicable Goals/Tactics (Security Requirements Packages)
• For illustrative purposes, we’re not going to show the Requirements
document as a source of input
34
35. Proof of Concept – Threat Modeling Input
Enter Project Name: POC
Enter Location Reference: userLogon1
Select Location Type [1]:
1 - External Entity
2 - Process
3 - Data Flow
4 - Data Store
1
Security Requirements Packages to Apply
1 - Authenticate Users: Robust authentication mechanism
2 - Authenticate Users: Protected authentication session
3 - Authenticate Users: Protected authentication session: Session Termination
4 - Authenticate Users: Protected authentication session: Limit Access
5 - Maintain Data Confidentiality: Protected confidentiality of transmitted data
6 - Maintain Integrity: Protected integrity of externally transmitted data
Enter list of goals (numbers separated by space): 1 2 3 4 5 6
Generating list of requirements... 35
36. Requirements Output
Result is 26 unique Common Criteria Security Functional Requirement
statements, e.g.:
• FCS_CKM.2: The TSF shall distribute cryptographic keys in accordance with
a specified cryptographic key distribution method [assignment:
cryptographic key distribution method] that meets the following:
[assignment: list of standards].
• FCS_CKM.4: The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method [assignment: cryptographic
key destruction method] that meets the following: [assignment: list of
standards].
• TSF = TOE (Target of Evaluation) Security Functions 36
38. Summary of Requirements for TLS Connection
- Key distribution - Behavior when security attributes expire
- Secure back-end connections - Define & maintain roles
- Confidentiality, integrity & availability - Associate users with roles
- Replay protection - Provide reliable time stamps
- Error recovery - Scope session security attributes
- Authentication failure behavior - Limit concurrent sessions
- Permitted pre-authentication actions - Inactivity lock/unlock behavior
- Prevent & detect authentication forgery - Inactivity session termination
- Prevent & detect use of copied
authentication data
- Segmentation of different types of
communication (e.g., user vs. admin)
- Different privileges of local vs. remote
users
- Specify which endpoints initiate
connection
- Limit authentication feedback - Deny session based on attributes
- Control who can change security
attributes
- Force re-authentication when needed
- Key destruction 38
39. What We Demonstrated
• For a given component type (reusable security function), you can
specify applicable groupings of security requirements (SRPs)
• Each SRP can be configured as a set of detailed requirements
• They can include dependent requirements
• We can associate Threat Modeling mitigations to standardized
requirements packages—and their dependencies
• We can expand the list of requirements for later use
39
40. Requirements for a Complete Tool
The high-level re-entrant workflow concept to be used throughout the
Secure Software Development Lifecycle (SSDLC) includes:
• Build the security model –
• Direct input of instance of security component
• Select component by way of threat model taxonomy
• Expand the requirements utilizing a configurable library of Security
Requirements Packages, plus their dependencies
• Design status check-off of items already addressed, or inherited
• Enter level of effort and risk scoring data and provide a Risk-Benefit
Analysis ranking
40
41. Requirements for a Complete Tool (cont’d)
• Risk decision step to fix or accept risk, documenting any risk
acceptance justification
• Document any items deferred
• Generate list of security requirements changes to be addressed, and
update design status as fixed
• Output list of all security requirements implemented, or being
implemented, for documentation and testing purposes
• Output list of implemented, inherited, and deferred security controls
in desired format (ISO or NIST)
41
44. Location
External Entity
Process
Data Flow
Data Store
Create
Model
Builder
Expand
Requirements
Design
Status
Risk-
Benefit-
Analysis
Risk
Decision
Requirements
Change
Checklist
Finalize
Requirements
Output Test
Requirements
Output
Security
Controls
New
ComponentUser Server
Component Name
userLogon1
Spoof Client
Obtain credentials
Authentication UI
No authentication
Other authentication attack
Insufficient authentication
Backup authentication
Obtain Credentials
Transit
Change management
Federation issues
Storage
Mitigation
SSL
IPsec
TLS
Other
Input Mode
Threat Model
Direct
43
45. Create
Model
Builder Expand Requirements Design
Status
Risk-
Benefit-
Analysis
Risk
Decision
Requirements
Change
Checklist
Finalize
Requirements
Output Test
Requirements
Output
Security
Controls
44
Security Functional Requirements
Component Type:
TLS
Used by:
userLogon1
userLogon2
The TSF shall be able to deny session establishment based on [assignment:
attributes]. [FTA_TSE.1]
The TSF shall enforce the [assignment: access control SFP(s) and/or information flow
control SFP(s)] to be able to [selection: transmit, receive] user data in a manner
protected from unauthorised disclosure. [FDP_UCT.1]
The TSF shall enforce the [assignment: access control SFP(s) and/or information flow
control SFP(s)] to be able to recover from [assignment: list of recoverable errors]
with the help of the source trusted IT product. [FDP_UIT.2]
The TSF shall enforce the [assignment: access control SFP(s) and/or information flow
control SFP(s)] to prevent the [selection: disclosure, modification, loss of use] of user
data when it is transmitted between physically-separated parts of the TOE.
[FDP_ITT.1]
47. Create
Model
Builder
Expand
Requirements Design Status
Risk-
Benefit-
Analysis
Risk
Decision
Requirements
Change
Checklist
Finalize
Requirements
Output Test
Requirements
Output
Security
Controls
42
Security Functional Requirement
Component Type: TLS; Used by: userLogon1, userLogon2
Already Implemented
The TSF shall prevent reuse of authentication data related to [assignment: identified
authentication mechanism(s)]. [FIA_UAU.4]
The TSF shall re-authenticate the user under the conditions [assignment: list of
conditions under which re-authentication is required]. [FIA_UAU.6]
The TSF shall enforce the [assignment: access control SFP(s) and/or information
flow control SFP(s)] to be able to recover from [assignment: list of recoverable
errors] with the help of the source trusted IT product. [FDP_UIT.2]
The TSF shall enforce the [assignment: access control SFP(s) and/or information
flow control SFP(s)] to prevent the [selection: disclosure, modification, loss of use]
of user data when it is transmitted between physically-separated parts of the TOE.
[FDP_ITT.1]
Y
Y
48. Create
Model
Builder
Expand
Requirements
Design
Status
Risk-Benefit-
Analysis
Risk
Decision
Requirements
Change
Checklist
Finalize
Requirements
Output Test
Requirements
Output
Security
Controls
42
Security Functional Requirement
Component Type: TLS; Used by: userLogon1, userLogon2
Risk LOE Ranking
The TSF shall be able to deny session establishment based on
[assignment: attributes]. [FTA_TSE.1]
M $ 50,000 10
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to be able to [selection: transmit,
receive] user data in a manner protected from unauthorised disclosure.
[FDP_UCT.1]
H $ 20,000 50
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to be able to recover from [assignment:
list of recoverable errors] with the help of the source trusted IT product.
[FDP_UIT.2]
L $ 30,000 3
The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to prevent the [selection: disclosure,
modification, loss of use] of user data when it is transmitted between
physically-separated parts of the TOE. [FDP_ITT.1]
M $ 30,000 17
49. Create
Model
Builder
Expand
Requirements
Design
Status
Risk-
Benefit-
Analysis
Risk Decision
Requirements
Change
Checklist
Finalize
Requirements
Output Test
Requirements
Output
Security
Controls
42
Security Functional Requirement
Component Type: TLS; Used by: userLogon1, userLogon2
Risk LOE Ranking
Fix
Decision
The TSF shall be able to deny session establishment based on
[assignment: attributes]. [FTA_TSE.1]
M $ 50,000 10
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to be able to
[selection: transmit, receive] user data in a manner protected
from unauthorised disclosure. [FDP_UCT.1]
H $ 20,000 50 Yes
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to be able to recover
from [assignment: list of recoverable errors] with the help of
the source trusted IT product. [FDP_UIT.2]
L $ 30,000 3
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to prevent the
[selection: disclosure, modification, loss of use] of user data
when it is transmitted between physically-separated parts of
the TOE. [FDP_ITT.1]
M $ 30,000 17 Yes
50. Create
Model
Builder
Expand
Requirements
Design
Status
Risk-
Benefit-
Analysis
Risk Decision
Requirements
Change
Checklist
Finalize
Requirements
Output Test
Requirements
Output
Security
Controls
42
Security Functional Requirement
Component Type: TLS; Used by: userLogon1, userLogon2
Risk LOE Ranking Fix Decision
The TSF shall be able to deny session establishment based on
[assignment: attributes]. [FTA_TSE.1]
M $ 50,000 10 Defer
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to be able to [selection:
transmit, receive] user data in a manner protected from
unauthorised disclosure. [FDP_UCT.1]
H $ 20,000 50 Yes
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to be able to recover
from [assignment: list of recoverable errors] with the help of the
source trusted IT product. [FDP_UIT.2]
L $ 30,000 3
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to prevent the [selection:
disclosure, modification, loss of use] of user data when it is
transmitted between physically-separated parts of the TOE.
[FDP_ITT.1]
M $ 30,000 17 Yes
Defer Until
Release 2.3
51. Create
Model
Builder
Expand
Requirements
Design
Status
Risk-
Benefit-
Analysis
Risk Decision
Requirements
Change
Checklist
Finalize
Requirements
Output Test
Requirements
Output
Security
Controls
42
Security Functional Requirement
Component Type: TLS; Used by: userLogon1, userLogon2
Risk LOE Ranking Accept
The TSF shall be able to deny session establishment based on
[assignment: attributes]. [FTA_TSE.1]
M $ 50,000 10 Defer
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to be able to
[selection: transmit, receive] user data in a manner protected
from unauthorised disclosure. [FDP_UCT.1]
H $ 20,000 50 Yes
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to be able to recover
from [assignment: list of recoverable errors] with the help of
the source trusted IT product. [FDP_UIT.2]
L $ 30,000 3 No
The TSF shall enforce the [assignment: access control SFP(s)
and/or information flow control SFP(s)] to prevent the
[selection: disclosure, modification, loss of use] of user data
when it is transmitted between physically-separated parts of
the TOE. [FDP_ITT.1]
M $ 30,000 17 Yes
Enter Justification
Not critical. Can re-initiate
session
57. What Makes This Approach Unique
• Assists in enumerating requirements by applying standardized
Security Requirements Packages, then expanding the requirements
based on well-defined dependencies
• Includes chosen or default mitigations from a standardized Threat
Model taxonomy & generates more detailed security requirements
and controls
• Enables Risk-Benefit Analysis of each security requirement/control
• Facilitates generating documentation needed for testing and
compliance purposes
57
58. Benefits of Such a Methodology/Tool
• Enable characterizing security variables so that they may be
controlled, which is the key to establishing order from chaos
• Provide a way of enumerating design flaws, errors and omissions—
which may account for 1/3rd of vulnerabilities (CWEs)
• Enable enumeration of security functionality
• Identified in the solution space
• Not detailed in the original Requirements Document
58
59. Benefits of Such a Methodology/Tool (cont’d)
• Facilitate decision-making using Risk-Benefit Analysis of each
technical security control, generating acceptance of risk
documentation and record of deferred items
• Enable us to generate details needed to implement enumerated
requirements—for design and coding changes, plus unit, integration,
and QA testing
• Provide details for system security plans in ISO and NIST formats
• Integrate with systems engineering modeling tools via SysML
59
60. Theory – Did we come close to proving?
• Enable establishing order where there is currently chaos
regarding the identification and satisfaction of security
requirements during software development?
• Is this approach part of what is needed to establish security
engineering as a formal discipline?
• Does it solve a real problem? Which one?
60
61. Future of this Tool
• Basic functionality in prototype
• Support for requirement decision-making dialogues, context inputs
• Enable tailoring and completion of requirements language
• Provide support for configurable standardized Threat library &
associated mitigations
• Make freely available as an online service
• Open up Security Requirements Packages and Threat Library for
community development
• Three phases of development:
• Standalone/online (open source/funding/partners ?)
• Shared / Systems Roll-up / Performance Testing / Enterprise version
• SysML-capable / Integration with other tools 61
62. Wrap-Up
• Does this make sense?
• Is it useful?
• Who would use it?
• Who would buy it?
• Who would invest in it?
• If open sourced, would anybody really work on it?
• Should support for architecture and design patterns be included?
• If so, when? Scope? For requirements only?
• Questions & Discussion?
62
63. Contact Info
John M. Willis
Turnaround Security, Inc.
554 N Frederick Ave #244
Gaithersburg MD 20877 USA
(240) 720-7678
John.M.Willis@TurnaroundSecurity.com
LinkedIn.com/in/johnmwillis
63
Editor's Notes
Note that terminology may not be aligned with SABSA
Make sure you have had your coffee, tea, or Guinness
Tool will allow input during architecture and design process, or threat modeling process.
For example, adding a TLS connection as the input will result in …
… this more detailed list of requirements to consider…
We will come back to this slide later…
Let’s back up a little bit in time…
Repeat last bullet – Security Engineering is NOT a formal discipline – yet.
So, let’s jump right in. Software development starts with Requirements. We have to take into consideration…
Now let’s focus on the solution space challenges.
Level set
What do we have to work with? What has been done in researching this?
Aspect is concerned with cross-cutting issues. There has been some progress at integrating security concerns into low level UML models.
KAOS modeling is generally used for requirements engineering at a high level for business requirements.
So… what is our current state?
Systems Security Engineering Capability Maturity Model / Build Security In Security Model
Systems Security Engineering - An Integrated Approach to Building Trustworthy Resilient Systems
What do we need in the architecting & design, or solution phase?
How we should be testing security? We need the following inputs
What are the relevant variables?
What are the relevant variables?
Different types of applications/domains have different statistical distributions of the SFRs.
Note complete codes such as for Access control FDP_ACC.1.
Who says the package is right? The security architect.
Packages are standardized based on type of platform.
During architecture and design phase certain requirements may be excluded based on specific requirements, deign and environment.
Next three slides are just a subset of Preschern’s work. S=Strategy; G=Goal. Note S2, S3 & G10
Note decision diamond (2FA vs single factor). Has to be accommodated by tool. Not yet, though.
Selection of the applicable goals is a function of what you are trying to do and the environment (i.e., use case).
These are more broad and not as specific as Wu’s. Point is that there are rational ways to form SRPs.
Only G10 (Confidentiality of Transmitted information) relates to TLS
Later we will include G6 for our TLS connection
An “O” in a cell means Optional, based on a decision using information
A “-” means it is required indirectly. So far, we have not included optional or indirect requirements in the imported data
Note use of STRIDE and DFD… We are going to focus on Spoofing Authentication from an External Entity (client).
Note: B-#s refer to sections in Appendix B.
Entire tree is one possible starting point for a complete taxonomy. Each of these boxes can be encoded, or codified …
And here is Spoof Client. For each of these threats there are mitigations to consider. We are going to focus on Obtain Credentials in Transit
Encryption & authentication needed. Mitigation options include SSL, IPsec & SSH. Because we are working with a web app SSL (TLS) applies.
The tool mayneed to have some context awareness.
The key point is to standardize your threat modeling taxonomy – start somewhere. Standardize your process to minimize subjectivity.
Findings, impact, LOE are outputs of Threat Modeling. This tool would assist in managing threat information and matching it up with mitigations.
Here we have two examples – creation and destruction of keys.
Note the presence of the brackets. Your organization would tailor these in the requirements library based on your standards and preferred methods.
For our purposes, we’ll refer to these as Primary, Secondary and Tertiary SFRs. The Primary SFRs are specified in the SRPs that were selected.
11 instances of dependent requirements. 5 unique secondary requirements, and 1 unique tertiary requirement.
Would you think to address all of these? How about “Deny session based on attributes”? Did you check revocation status of the client certificate?
Some of these may not apply to a TLS connection, per se, but you may still need to take them into consideration. For example, how to know what role the user has.
What are the requirements for a complete tool?
Create: Application Type: Web, Desktop, Server, Mobile
Mock-up: Chose Direct Input Mode for architecture and design activities, or Threat Model for Threat Model data input. Here we choose Direct.
This screen is a DFD view, with only instances of node types visible.
Mock-up: Example Threat Tree navigation for Threat Model Input Mode.
Need to add DFD borders? Repeat: Two different input modes: Direct for design, and Threat Model
userLogon1 & userLogon2
Ranking is basically a product of Risk x inverse of Cost to Fix
The higher the Ranking the higher the priority to fix