Secure Software Design - C706

अब Quizwiz के साथ अपने होमवर्क और परीक्षाओं को एस करें!

Security Assessment A1 Questions

1. How critical is the software to meeting the customers' mission? 2. What security objectives are required by the software [e.g., confidentiality, integrity, and availability (CIA), as described in Lesson 1]? 3. What regulations and policies are applicable in determining what is to be protected? 4. What threats are possible in the environment where the software will be operating?

Defense in Depth

A defense that uses multiple types of security devices to protect a network. Also called layered security.

Agile Development

A software development methodology that delivers functionality in rapid iterations, requiring frequent communication, development, testing, and delivery. based on both iterative and incremental development methods a time-boxed iterative approach that facilitates a rapid and flexible response to change, which in turn encourages evolutionary development and delivery while promoting adaptive planning, development, teamwork, collaboration, and process adaptability throughout the lifecycle of the project

Software Development Lifecycle

A software development process used to reduce software maintenance costs and increase reliability of software concerning software security related bugs 1: reduce the number of security vulnerabilities and privacy problems 2: reduce the severity of the vulnerabilities that remain

Spoofing

A threat action that is designed to illegally access and use another user's credentials, such as username and password—Authentication

Modeling Software

A way to envision the interactions of the proposed software within its intended environment. The better the model reflects the intended environment, the more useful the modeling approach becomes

A2 - Architecture

A2 Policy compliance analysis SDL policy assessment and scoping Threat modeling / architecture security analysis Open source section (if needed) Privacy information gathering and analysis

A3 - Design & Development

A3 Policy compliance analysis Security test plan execution Static Analysis Threat model updating Design security analysis and review Privacy Implementation Assessment

A4 - Design & Development

A4 Policy compliance analysis Security test case execution Static Analysis Dynamic analysis Fuzz testing Manual code review Privacy validation and remediation

A5 - Ship

A5 Policy compliance analysis Final security review Vulnerability scan Penetration testing Open source licensing review Final security review Final privacy review

Software Security

About building security into the software through a SDL in an SDLC

NonFunctional Requirements

Address how well the functional requirements are met, or to put it another way, they constrain the functional requirements to specified operating ranges like guardrails on a highway-you are free to operate on the road within the boundaries of the guardrails.

Scrum

An iterative and incremental Agile software development method for managing software projects and product or application development empirical approach The basic unit of development for Scrum is called a "sprint," and a sprint can last from one week to one month

Privacy Impact Assessment (PIA)

Before developing this component, you will need to evaluate what regulatory legislation or policies are applicable to the software you are developing, called the data sensitivity assessment An effective PIA evaluates the sufficiency of privacy practices and policies with respect to legal, regulatory and industry standards, and maintains consistency between policy and practice.

Threat Modeling: Key Steps

Break down your product architecture using data flow diagrams Use STRIDE threat categories to identify what threats are applicable to each element of the data flow diagram. Map all threats with relevant vulnerabilities as applicable in the context of the usage scenario. Rank threats. Assign a risk rating to each threat and vulnerability to understand the impact; this will help define the priority for fixing. Use DREAD or other methodologies. Define the mitigation plan/countermeasures for each of the vulnerabilities identified. Fix the vulnerabilities that are not acceptable to the business in order of priority as decided in the preceding steps

BSIMM

Building Security In Maturity Model. The BSIMM is a study of real-world software security initiatives organized so that you can determine where you stand with your software security initiative and how to evolve your efforts over time

A2 - Deliverables

Business requirements - Software requirements, including CIA Threat modeling artifacts - Data flow diagrams, elements, threat listing Architecture threat analysis - Prioritization of threats and risks based on threat analysis Risk mitigation plan - Plan to mitigate, accept, or tolerate risk Policy compliance analysis - Analysis of adherence to company policies

CERT, Bugtraq, and SecurityFocus

CERT provides timely alerts on security vulnerabilities as well as a weekly summarized bulletin on vulnerabilities Bugtraq is an electronic security mailing list that provides information on security vulnerabilities as well as security bulletins and announcements from vendors Bugtraq is part of the SecurityFocus security portal which is currently owned by Symantec

Typical SDLC Phases

Concept Planning Design & Development Readiness Release & Launch Support & Sustain

SDL Security Goals

Confidentiality Integrity Availability

Security Properties

Confidentiality: Data is only available to the people intended to access it. Integrity: Data and system resources are only changed in appropriate ways by appropriate people. Availability: Systems are ready when needed and perform acceptably. Authentication: The identity of users is established (or you're willing to accept anonymous users). Authorization: Users are explicitly allowed or denied access to resources. Nonrepudiation: Users can't perform an action and later deny performing it.

Escalation of Privileges

Considered so important that it is the theme of a Microsoft Security Development Lifecycle card game designed to train developers and security professionals to quickly and easily find threats to software or computer systems

implement a test plan

Define test scripts Define the user community Identify the showstoppers Identify internal resources Identify external resources

software security policy

Define what needs to be protected and how it will be protected, including reviewing and incorporating policies from outside the SDL that may impact the development process. These might include policies governing software or applications developed or applied anywhere in the organization

Functional Requirements

Describe what an application must do to serve a business need. For example, an application must be able to allow a consumer to complete their transaction on the site using a credit card

Waterfall Development

Development method that focuses on completing each stage of the SDLC for the entire project before moving onto the next. typically higher-risk, more costly, and less efficient than the Agile approach Since the plan is not to revisit a phase using this methodology once it is completed, it is imperative that you do it right the first time: There is generally no second chance

Mitigation Responses

Do nothing: for example, hope for the best. Inform about the risk: for example, warn your user population about the risk. Mitigate the risk: for example, by putting countermeasures in place. Accept the risk: for example, after evaluating the impact of the exploitation (business impact). Transfer the risk: for example, through contractual agreements and insurance.

Availability

Ensuring timely and reliable access to and use of information

Post-Release Support PRSA 1-5

External vulnerability disclosure response 3rd Party reviews Post-release certifications Internal review for new product combinations or cloud deployment Security architectural review and tool-based assessments of current legacy and M&A products and solutions

mitigation threat profile

Fully mitigated threats: Threats that have appropriate countermeasures in place and do not expose vulnerability or cause impact. Partially mitigated threats: Threats partially mitigated by one or more countermeasures, which represent vulnerabilities that can only partially be exploited and cause a limited impact. Non-mitigated threats: Threats that have no countermeasures and represent vulnerabilities that can be fully exploited and cause an impact

Fuzzing

Fuzz testing or fuzzing is a black-box software testing technique which can be automated or semi-automated, which provides invalid, unexpected, or random data to the inputs of a computer software program. In other words, it finds implementation bugs or security flaws by using malformed/semi-malformed data injection in an automated fashion Codenomicon & Peach Fuzzing Tool

Integrity

Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity

Threat Model Updating

Have you accounted for all the policies, laws, or regulations relevant to the software Have all your stakeholders reviewed the security assessment and risks identified as a result of the threat modeling process Have you accounted for and have your stakeholders agreed to the availability of time and resources required as both a result of the threat modeling process and any resulting mitigation and testing Have you ranked your threats and risks according to consensus from stakeholders

A2 - Key Success Factors

Identification of business requirements and risks - Mapping of business requirements and risks defined in terms of CIA 2.Effective threat modeling - Identifying threats for the software 3.Effective architectural threat analysis - Analysis of threats to the software and probability of threat materializing 4.Effective risk mitigation strategy - Risk acceptance, tolerance, and mitigation plan per business requirements 5.Accuracy of DFDs - Data flow diagrams used during threat modeling

threat modeling

Identify security objectives. Survey the application. Decompose it. Identify threats. Identify vulnerabilities. help you understand what assets you need to protect, from whom you need to protect them, how you can protect them, what is the implementation priority, and what risk you will have to live with if a few of the threats are not included in the implementation scope

Leveraging existing components

In many instances, the security mechanisms of an information system are not configured properly or used to their maximum capability. Reviewing the state and settings of the extant security mechanisms and ensuring that they are operating at their optimum design points will greatly improve the security posture of an information system. Another approach that can be used to increase system security by leveraging existing components is to partition a system into defended subunits. Then, if a security mechanism is penetrated for one subunit, it will not affect the other subunits and damage to the computing resources will be minimized

kick-off meeting

It is important in initial formalized meetings, when the software security team is included, to ensure that security is a key element of the SDLC and is built into the process

Weakest link

It is important to identify the weakest mechanisms in the security chain and layers of defense and improve them so that risks to the system are mitigated to an acceptable level

Metrics

Metrics tracking is like an insurance policy for your software projects and also assists in managing protection against vulnerabilities Security metrics can be an invaluable resource for assessing the effectiveness of an organization's software security program

Privacy Implementation Assessment

One of the best ways to protect a customer's privacy is not to collect his or her user data in the first place. The questions that should constantly be asked by architects, developers, and administrators of data collection systems include: "Do I need to collect this data?" "Do I have a valid business purpose?" "Will customers support my business purpose? Customers must provide consent before any personal information is transferred from their computer; and If customers' personal information is transferred over the Internet and stored remotely, they must be offered a mechanism for accessing and updating the information

threat modeling: Design Principles

Open design: Assume the attackers have the sources and the specs. Fail-safe defaults: Fail closed; no single point of failure. Least privilege: No more privileges than what is needed. Economy of mechanism: Keep it simple, stupid. Separation of privileges: Don't permit an operation based on a single condition. Total mediation: Check everything, every time. Least common mechanism: Beware of shared resources. Psychological acceptability: Will they use it?

Privacy Implementation Assessment

P1: High Privacy Risk. The feature, product, or service stores or transfers personally identifiable information (PII), changes settings or file type associations, or installs software. P2: Moderate Privacy Risk. The sole behavior that affects privacy in the feature, product, or service is a one-time, user-initiated, anonymous data transfer (for example, the user clicks on a link and the software goes out to a website). P3: Low Privacy Risk. No behaviors exist within the feature, product, or service that affect privacy. No anonymous or personal data is transferred, no PII is stored on the machine, no settings are changed on the user's behalf, and no software is installed

Confidentiality

Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information

PSIRT

Product Security Incident Response Team a team solely dedicated to conducting security M&A assessments, third-party reviews, post-release certifications, internal reviews for new product combinations of cloud deployments, and review for legacy software that is still in use or about to be re-used

Application Security

Protecting the software and the systems on which it runs after release

Risk

Risk = Probability × Damage Potential

Project Plan

SDL project plan should outline security milestones based on the information gained during the discovery phase and integrate them into the overall SDLC schedule to allow proper planning as changes occur

Secure code vs Quality Code

Secure code does not mean quality code Quality code does not mean secure code

A1 - Security Assessment

Software security team is looped in early Software security team hosts a discovery meeting Software security team creates an SDL project plan (states what further work will be done) Privacy Impact Assessment (PIA) plan initiated

STRIDE Model

Spoofing Tampering Repudiation Information Disclosure Denial of Service Elevation of Privilege

Security Test Plan Composition

Testing activities validate the secure implementation of a product, which reduces the likelihood of security bugs being released and discovered by customers and/or malicious users

DREAD

The acronym DREAD stands for Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. Answers to questions used to establish a risk rating for each of these elements produces a number from 0 -10; the higher the number, the more serious is the risk Risk DREAD= (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) /5

Least privilege

The principle of least privilege maintains that an individual, process, or other type of entity should be given the minimum privileges and resources for the minimum period of time required to complete a task. This approach eliminates the opportunity for unauthorized access to sensitive information

Information security

The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability

Deliverables for A1 - Security Assessment

The tangible documented outcome of all required activities Product risk profile, SDL project outline (for security milestones and mapping to development schedule), Applicable laws and regulations, Threat profile, Certification requirements, List of third-party software, Metrics template.

Risk Mitigation

There are four ways you can plan mitigation and address threats: 1. Redesign the process to eliminate the threat. 2. Apply a standard mitigation as per general recommendations. 3. Invent a new mitigation strategy (risky and time-consuming) 4. Accept vulnerabilities with low risk and high effort to fix them.

Open design

There has always been discussion of the merits and strength of security of designs that are kept secret versus designs that are open to scrutiny and evaluation by the community at large. For most purposes, an open-access control system design that has been evaluated and tested by a large number of experts provides a more secure authentication method than one that has not been widely assessed

A4 Policy Compliance Analysis

This is a continuation of the A3 policy compliance review any policy that exists outside the domain of the SDL policy is reviewed and may include policies from outside the development organization

Defense in depth

This is the application of multiple layers of protection, such that a subsequent layer will provide protection if a previous layer is breached.

Complete mediation

This is where every request by a subject to access an object in a computer system must undergo a valid and effective authorization procedure. This mediation must not be suspend or become capable of being bypassed, even when the information system is being initialized, undergoing shutdown, being restarted, or is in maintenance mode. Complete mediation entails: identification of the entity making the access request verification that the request has not changed since its initiation application of the appropriate authorization procedures and reexamination of previously authorized requests by the same entity.

Fail safe

This means that if a system fails, it should fail to a state where the security of the system and its data are not compromised. In the situation where system recovery is not done automatically, the failed system should permit access only by the system administrator and not by users, until security controls are reestablished

Separation of duties

This principle requires that completion of a specified sensitive activity or access to sensitive objects is dependent on the satisfaction of multiple conditions. Separation of duties forces collusion among entities in order to compromise the system

Least common mechanism

This principle states that a minimum number of protective mechanisms should be common to multiple users, as shared access paths can be sources of unauthorized information exchange. Shared access paths that provide unintentional data transfers are known as covert channels. The least common mechanism promotes the least possible sharing of common security mechanisms

Economy of mechanism

This promotes simple and comprehensible design and implementation of protection mechanisms, so that unintended access paths do not exist or can be readily identified and eliminated

Psychological acceptability

This refers to the ease of use and intuitiveness of the user interface that controls and interacts with the access control mechanisms. The user must be able to understand the user interface and use it without having to interpret complex instructions

Tampering

Threat action aimed to maliciously change/modify persistent data, such as persistent data in a database, and the alteration of data in transit between two computers over an open network, such as the Internet—Integrity

Repudiation

Threat action aimed to perform illegal operations in a system that lacks the ability to trace the prohibited operations—Nonrepudiation

Information disclosure

Threat action to read a file that one was not granted access to, or to read data in transit—Confidentiality

Denial of service

Threat aimed to deny access to valid users, such as by making a Web server temporarily unavailable or unusable—Availability

Elevation of privilege

Threat aimed to gain privileged access to resources for gaining unauthorized access to information or to compromise a system—Authorization

Threat Modeling

Understand the potential security threats to the system, determine risk, and establish appropriate mitigations (What? How bad is it? How can it be fixed?) the earlier security risks are identified and managed in the software lifecycle, the better

Software security testing techniques

White box. Testing from an internal perspective, i.e., with full knowledge of the software internals; the source code, architecture and design documents, and configuration files are available for analysis. - Source code analysis, Property-based, ( half Source-code fault injection) Gray box. Analyzing the source code for the purpose of designing the test cases, but using black-box testing techniques; both the source code and executable binary are available for analysis. - (half Source-code fault injection), Dynamic code analysis, (half Binary fault injection) Black box. Testing the software from an external perspective, i.e., with no prior knowledge of the software; only binary executable or intermediate byte code is available for analysis - (half Binary fault injection), Fuzz testing, Binary code analysis, Byte code analysis, Black box debugging, Vulnerability scanning, Penetration testing

SANS Institute Top Cyber Security Risks

a consensus list of the most critical problem areas in Internet security that require immediate remediation if present on your systems. Step-by-step instructions and pointers to additional information useful for correcting these security flaws are included as part of the list

Data Flow Diagram

a graphical description of the flow of data within an organization, including data sources/destinations, data flows, transformation processes, and data storage first step of the threat modeling process is to develop a visual representation of the threat flows in the form of a diagram

MITRE Corporation Common Computer Vulnerabilities and Exposures

a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities with this "common enumeration."

Least Privilege

a principle that users be granted the privilege for some activity only if there is a justifiable need to grant this authorization

Threat analysis

a systematic procedure designed to identify and eliminate identifiable safety risks We divide these into broad categories of: input validation, authentication, authorization, configuration management, sensitive data, session management, cryptography, exception management, parameter manipulation, and audit and logging

OWASP

an industry-standard resource that is used by development organizations to raise awareness of the most critical web application vulnerabilities. It provides a deep understanding of the cause of security risks, ways to prevent vulnerabilities in the development life cycle, and ways to test applications to ensure that Top 10 vulnerabilities have been addressed or remediated

The Generic Risk Model

assigning qualitative values such as high, medium, and low to likelihood and impact factors Risk=Likelihood×Impact

A3 Policy Compliance Analysis

continuation of the A2 policy compliance review any policy that exists outside the domain of the SDL policy is reviewed we continue to perform policy compliance analysis during different phases and review it again and again

A5 Policy Compliance Analysis

covers all projects that have meaningful security and privacy risks and is analyzed in each phase and updated to cover new threats and practices

A2 Policy Compliance Analysis

define what needs to be protected and how it will be protected, including reviewing and incorporating policies from outside the SDL that may impact the development process. These might include policies governing software or applications developed or applied anywhere in the organization.

Discovery meeting

essentially a SDL kick-off meeting where the key SDLC stakeholders get on the same page at the beginning of the process so that security is built in rather than bolted on post-release

OWASP Software Assurance Maturity Model (SAMM)

flexible and prescriptive framework for building security into a software development organization self-assess their security assurance program and then use recommended roadmaps to improve in a way that is aligned to the specific risks facing the organization

National Institute of Standards and Technology

great value in providing research, information, and tools for both the government and corporate information security community NIST SAMATE (Software Assurance Metrics And Tool Evaluation) project is dedicated to improving software assurance by developing methods to enable software tool evaluations, measuring the effectiveness of tools and techniques, and identifying gaps in tools and methods The National Vulnerability Database (NVD) is the U.S. government repository of standards-based vulnerability management data represented using the Security Content Automation Protocol (SCAP)

Iterative Waterfall Development

improvement on the standard Waterfall model less risk than a traditional Waterfall approach but is more risky and less efficient than the Agile approach overall project is divided into various phases, each executed using the traditional Waterfall method

Dynamic Analysis

is the analysis of computer software that is performed by executing programs on a real or virtual processor in real time. The objective is to find security errors in a program while it is running, rather than by repeatedly examining the code offline. By debugging a program in all the scenarios for which it is designed, dynamic analysis eliminates the need to artificially create situations likely to produce errors

Static Analysis

is the analysis of computer software that is performed without actually executing programs. It is predominantly used to perform analysis on a version of the source code; however, this kind of analysis may also be done on some form of the object code. In contrast, dynamic analysis is performed by actually executing software programs

static analysis tools

look for a fixed set of patterns or rules in the code in a manner similar to virus-checking programs

SAFECode

nonprofit organization dedicated to increasing trust in information and communications technology products and services through the advancement of effective software assurance methods. SAFECode is a global, industry-led effort to identify and promote best practices for developing and delivering more secure and reliable software, hardware, and services

U.S. Department of Defense Cyber Security and Information Systems Information Analysis Center (CSIAC)

performs the Basic Center of Operations (BCO) functions necessary to fulfill the mission and objectives applicable to the DoD(RDT&E) and Acquisition communities' needs for cyber security, information assurance, knowledge management and information sharing, software-intensive systems engineering, and modeling and simulation

principle of least privilege

requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.

Software Security Architects

responsible for providing architectural and technical guidance to product security across all of Company X. The Architect will design, plan, and implement secure coding practices and security testing methodology; ensure that practices meet software certification processes; drive the security testing of the products; test and evaluate security-related tools; and manage third-party vendors to meet those responsibilities above

U.S. Department of Homeland Security Software Assurance Program

seeks to reduce software vulnerabilities, minimize exploitation, and address ways to improve the routine development and deployment of trustworthy software products Common Weakness Enumeration (CWE)

Lean Development

similar to Scrum in that it focuses on features rather than groups of features, it takes this idea one step further in that, in its simplest form, you select, plan, develop, test, and deploy one feature before you select, plan, develop, test, and deploy the next feature

Attack Surface

testing should cover the entry points and exit points of an application that may be accessible to an attacker ex. code that is restricted to local access by an administrator has a smaller attack surface than code exposed to remote access by an anonymous user

Authorization and authentication

two properties that support confidentiality authorization ensures that the user has the appropriate role and privilege to view data authentication ensures that the user is who he or she claims to be and that the data come from the appropriate place.

Application Security Frame

uses categories to organize common security vulnerabilities focused on Web software applications. If you use these categories when you review your application design to create a threat model, you can systematically reveal the threats and vulnerabilities specific to your application architecture

Software Security Champions

you may be asking yourself how you can ever scale to this task given the resources that security software and the development teams working with them will have. The answer is that if you manage the software security team or have that function working for you, you will use the recruitment and leverage of software security champions (SSCs) to manage this daunting task


संबंधित स्टडी सेट्स

Ch 24: Childbirth at Risk: Labor-related complications

View Set

Chapter 22: Long Run Economic Growth: Sources and Policies

View Set

Stress prevention quiz 10,11,12,13--pretest and postests, reading

View Set

Chapter 19: The Industrial Revolution and Nineteenth-Century Society

View Set