Secure Software Design - C706
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