Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
238 Cards in this Set
- Front
- Back
|
CSSLP?
|
Certified Secure Software Lifecycle Professional
|
|
|
What approach does CSSLP take?
|
Holistic approach covering people, processes, and technology elements in developing software.
|
|
|
Seven domains of the CSSLP Common body of knowledge (CBK)
|
1) Secure Software Concepts
2) " Requirements 3) " Design 4) " Implementation/Coding 5) " Testing 6) " Acceptance 7) " Deployment, Operations, Maintenance, and Disposal |
|
|
CSSLP?
|
Certified Secure Software Lifecycle Professional
|
|
|
What approach does CSSLP take?
|
Holistic approach covering people, processes, and technology elements in developing software.
|
|
|
Seven domains of the CSSLP Common body of knowledge (CBK)
|
1) Secure Software Concepts
2) " Requirements 3) " Design 4) " Implementation/Coding 5) " Testing 6) " Acceptance 7) " Deployment, Operations, Maintenance, and Disposal |
|
|
Holistically secure software secures:
|
The network, hosts, and application layers so there is no weak link.
|
|
|
Reasons why there is a prevalence of insecure software:
|
1) Iron triangle constraints of time/schedule, resources/scope/people, and cost/budget
2) Security as an afterthought because of lack on return on security investment but cost of fixing issues early is low 3) Security versus usability as it may increase complexity, restrictiveness, but see psychological acceptability. |
|
|
Quality and security differ in
|
that security may lead to quality while the inverse may not be true. Trust the quality but validate security.
|
|
|
What makes software secure?
|
A profile consisting of Core, General, and Design Security Concepts
|
|
|
Core Security Concepts
|
Confidentiality, Integrity, Availability
|
|
|
General Security Concepts
|
Authentication, Authorization, Auditting/Logging, Session Management, Errors and Exception Management, Configuration Parameters Management
|
|
|
Design Security Concepts
|
Least Privilege, Separation of duties, Defense in depth, Fail secure, Economy of mechanism, Complete mediation, Open design, Least common mechanisms, Psychological acceptability, Leveraging existing components, Weakest link, Single point of failure
|
|
|
Do security concepts span across the entire SDLC?
|
Yes, it helps in risk management for example see NIST 800-64
|
|
|
Risk management in the context of software security is
|
the balancing act between the protection of IT assets and cost of implementing software security controls so that risk is handled properly. See NIST 800-30.
|
|
|
Define Asset
|
(In)tangile Items of value, the loss of which can cause disruptions in missions accomplishment.
|
|
|
Define Vulnerability
|
A weakness or flaw that could be exploited, resulting in security policy breaches across the SDLC (process, design, or implementation of a system).
|
|
|
Examples of process vulnerabilities
|
Improper source-code control, backups, access control.
|
|
|
Examples of design vulnerabilities
|
Using obsolete crypto algorithms such as DES, not handling resource deadlocks, unhandled exceptions, hard-coding db connections.
|
|
|
Examples of implementation vulnerabilities
|
Software accepts any user supplied data and processes it without first validating it; reveals too much information in the event of an error, not closing connections to backend dbs.
|
|
|
Some well-known vulnerability trackers and repositories
|
US-CERT, CVWW, OSVDB, CVE, CWE
|
|
|
Define Threat and its classes
|
A possible unwanted, unintended, or harmful event posed by vulnerabilities to assets in terms of disclosure, alteration, or destruction.
|
|
|
Define Threat Source / Agent
|
Anyone or anything that has the probability/likelihood to make a threat materialize.
|
|
|
Define Attack
|
When a source or agent materializes a threat
|
|
|
Define Probability
|
The likelihood that a particular threat can happen.
|
|
|
Define Impact
|
The extent of the disruptions to the organization's ability to achieve its goals
|
|
|
Define Exposure Factor
|
The opportunity for a threat to cause loss. A low exposure factor may reduce the overall risk of exploitation.
|
|
|
Define Controls
|
Technical, administrative, or physical mechanisms by which threats to software and systems can be mitigated.
|
|
|
Define Total Risk
|
The likelihood of attack in terms of asset value, threat, and vulnerabilities.
|
|
|
Define Residual Risk
|
The remaining risk after the implementation of mitigating security controls.
|
|
|
How is risk conventionally expressed?
|
As the product of the probability of a threat source/agent taking advantage of a vulnerability and the corresponding impact.
|
|
|
How is risk classically calculated?
|
Annual Loss Expectancy = SLE(Asset value x Exposure Factor) x ARO (threat occurrence expectation in a year)
|
|
|
What is the primary goal of risk management?
|
The identification and reduction of the total risk using controls so that the residual risk is within the acceptable range or threshold, wherein business operations are not disrupted.
|
|
|
The most effective way to ensure that software developed has taken into account security threats and addressed vulnerabilities, thereby reducing overall risk of that software.
|
Incorporate risk management processes into the SDLC itself.
|
|
|
CSSLP?
|
Certified Secure Software Lifecycle Professional
|
|
|
What approach does CSSLP take?
|
Holistic approach covering people, processes, and technology elements in developing software.
|
|
|
Seven domains of the CSSLP Common body of knowledge (CBK)
|
1) Secure Software Concepts
2) " Requirements 3) " Design 4) " Implementation/Coding 5) " Testing 6) " Acceptance 7) " Deployment, Operations, Maintenance, and Disposal |
|
|
Holistically secure software secures:
|
The network, hosts, and application layers so there is no weak link.
|
|
|
Reasons why there is a prevalence of insecure software:
|
1) Iron triangle constraints of time/schedule, resources/scope/people, and cost/budget
2) Security as an afterthought because of lack on return on security investment but cost of fixing issues early is low 3) Security versus usability as it may increase complexity, restrictiveness, but see psychological acceptability. |
|
|
Quality and security differ in
|
that security may lead to quality while the inverse may not be true. Trust the quality but validate security.
|
|
|
What makes software secure?
|
A profile consisting of Core, General, and Design Security Concepts
|
|
|
Core Security Concepts
|
Confidentiality, Integrity, Availability
|
|
|
General Security Concepts
|
Authentication, Authorization, Auditting/Logging, Session Management, Errors and Exception Management, Configuration Parameters Management
|
|
|
Design Security Concepts
|
Least Privilege, Separation of duties, Defense in depth, Fail secure, Economy of mechanism, Complete mediation, Open design, Least common mechanisms, Psychological acceptability, Leveraging existing components, Weakest link, Single point of failure
|
|
|
Do security concepts span across the entire SDLC?
|
Yes, it helps in risk management for example see NIST 800-64
|
|
|
Risk management in the context of software security is
|
the balancing act between the protection of IT assets and cost of implementing software security controls so that risk is handled properly. See NIST 800-30.
|
|
|
Define Asset
|
(In)tangile Items of value, the loss of which can cause disruptions in missions accomplishment.
|
|
|
Define Vulnerability
|
A weakness or flaw that could be exploited, resulting in security policy breaches across the SDLC (process, design, or implementation of a system).
|
|
|
Examples of process vulnerabilities
|
Improper source-code control, backups, access control.
|
|
|
Examples of design vulnerabilities
|
Using obsolete crypto algorithms such as DES, not handling resource deadlocks, unhandled exceptions, hard-coding db connections.
|
|
|
Examples of implementation vulnerabilities
|
Software accepts any user supplied data and processes it without first validating it; reveals too much information in the event of an error, not closing connections to backend dbs.
|
|
|
Some well-known vulnerability trackers and repositories
|
US-CERT, CVWW, OSVDB, CVE, CWE
|
|
|
Define Threat and its classes
|
A possible unwanted, unintended, or harmful event posed by vulnerabilities to assets in terms of disclosure, alteration, or destruction.
|
|
|
Define Threat Source / Agent
|
Anyone or anything that has the probability/likelihood to make a threat materialize.
|
|
|
Define Attack
|
When a source or agent materializes a threat
|
|
|
Define Probability
|
The likelihood that a particular threat can happen.
|
|
|
Define Impact
|
The extent of the disruptions to the organization's ability to achieve its goals
|
|
|
Define Exposure Factor
|
The opportunity for a threat to cause loss. A low exposure factor may reduce the overall risk of exploitation.
|
|
|
Define Controls
|
Technical, administrative, or physical mechanisms by which threats to software and systems can be mitigated.
|
|
|
Define Total Risk
|
The likelihood of attack in terms of asset value, threat, and vulnerabilities.
|
|
|
Define Residual Risk
|
The remaining risk after the implementation of mitigating security controls.
|
|
|
How is risk conventionally expressed?
|
As the product of the probability of a threat source/agent taking advantage of a vulnerability and the corresponding impact.
|
|
|
How is risk classically calculated?
|
Annual Loss Expectancy = SLE(Asset value x Exposure Factor) x ARO (threat occurrence expectation in a year)
|
|
|
What is the primary goal of risk management?
|
The identification and reduction of the total risk using controls so that the residual risk is within the acceptable range or threshold, wherein business operations are not disrupted.
|
|
|
The most effective way to ensure that software developed has taken into account security threats and addressed vulnerabilities, thereby reducing overall risk of that software.
|
Incorporate risk management processes into the SDLC itself.
|
|
|
Challenges to risk management for software:
|
* Still maturing
* Software asset values are often subjective * Limited data on the EF, Impact, and Probability of software security breaches * Technical security risk is only a portion of the overall state of secure software |
|
|
PCI DSS
|
Payment Card Industry Data Security Standard for the secure transmission and storage of credit card primary account number (PAN), etc.
|
|
|
Five possible ways to address risk (IAMAT):
|
1) Ignore the risk
2) Avoid the risk 3) Mitigate the risk 4) Accept the risk 5) Transfer the risk |
|
|
Summarize risk management concepts
|
1) Owners value assets and wish to minimize risk to assets
2) Threat agents wish to abuse or damage assets and give rise to threats that increase the risk to assets 3) Threats may exploit vulnerabilities leading to the risk to assets 4) When known, vulnerabilities may be reduced by implementing controls that reduce the risk to assets 5) Controls themselves may pose additional unforeseen vulnerabilities |
|
|
What is a security policy?
|
The what and why document. It specifies the assets that need to be protected and the possible repercussions of noncompliance. Also state's the organization's goals and objectives. Ensures nonrepudiation in the organization. Provides CIA guidance to architect secure software. May define the security team for incident responses, enforcement mechanisms, and for exception handling, rewards, discipline.
|
|
|
What may the scope be for an information security policy?
|
Organizational (global applicability) or functional (unit or specific issue applicability).
|
|
|
What are prerequisites for Security Policy Development?
|
1) Enforce-ability, top-level support
2) Inclusion of various teams 3) Marketing efforts that communicate mgmt goals |
|
|
Is security policy development a onetime activity?
|
No, the policy should be periodically evaluated so that they are contextually correct and relevant to address current-day threats.
|
|
|
High level security policies are supported by what?
|
More detailed security standards such as internal coding standards and external industry (PCI DSS), governmental (NIST), international (ISO), and national standards (FIPS).
|
|
|
Advantages attributable to using coding standards:
|
Consistency in style, improved readability, and maintainability (nonsecurity advantages). Less prone to errors and exposure to threats (security advantages).
|
|
|
What is PCI DSS?
|
Payment Card Industry Data Security Standard for the secure transmission and storage of credit card primary account number (PAN), etc.
|
|
|
PCI DSS control objectives
|
1) Build and maintain a secure network, 2) Protect cardholder data, 3) Maintain a vulnerability management program, 4) Implement strong access control, 5) Regularly monitor and test networks, 6) Maintain an information security policy
|
|
|
NIST's computer security division information technology laboratory (ITL) periodically publishes which special publications:
|
NIST Special Publication (SP) 500 and 800 series. NIST also publishes bulletins and computer security-related Federal Information Processing Standards (FIPS).
|
|
|
NIST SP which discusses security considerations in the information systems development lifecycle:
|
NIST SP 800-64
|
|
|
NIST SP "handbook" which discusses the benefits of different security controls and the scenarios in which they would be appropriately applicable:
|
NIST SP 800-12
|
|
|
NIST SP for generally accepted principle and practices for securing IT systems:
|
NIST SP 800-14
|
|
|
NIST SP risk management guide for IT
|
NIST SP 800-30
|
|
|
NIST SP for security considerations in the information systems development life cycle
|
NIST SP 800-64 (especially pertinent to CSSLPs)
|
|
|
NIST SP guide for managers in information security
|
NIST SP 800-100
|
|
|
What are ISO standards and what do they cover?
|
International Standards Organizations and they cover all sectors except electrotechnology (IEC) and telecommunications (ITU).
|
|
|
ISO/IEC standard for information security management system (ISMS) overviews and vocabulary:
|
ISO/IEC 27000:2009
|
|
|
ISO/IEC standard for information security management system (ISMS):
|
ISO/IEC 27001:2005
|
|
|
ISO/IEC standard for code of practice for information security management:
|
ISO/IEC 27002:2005/Cor1:2007
|
|
|
ISO/IEC standard concerning ISMS Implementation Guidance
|
ISO/IEC FCD 27003
|
|
|
ISO/IEC standard for information security risk management
|
ISO/IEC 27005:2008
|
|
|
ISO/IEC standard on requirements for bodies providing audit and certification of ISMS
|
ISO/IEC 27006:2007
|
|
|
ISO/IEC standard on evaluating criteria for IT security (Common Criteria)
|
ISO/IEC 15408, part1 introduces security functional and security assurance requirements (SFRs and SARs) along with the protection profile (PP), the security target (ST), and the target of evaluation (TOE). Part 2 contains the catalog of predefined SFRs as classes, families, and components. Part 3 defines the SARs and include the EALs for measuring assurance of a TOE.
|
|
|
CSSLP?
|
Certified Secure Software Lifecycle Professional
|
|
|
What approach does CSSLP take?
|
Holistic approach covering people, processes, and technology elements in developing software.
|
|
|
Seven domains of the CSSLP Common body of knowledge (CBK)
|
1) Secure Software Concepts
2) " Requirements 3) " Design 4) " Implementation/Coding 5) " Testing 6) " Acceptance 7) " Deployment, Operations, Maintenance, and Disposal |
|
|
Holistically secure software secures:
|
The network, hosts, and application layers so there is no weak link.
|
|
|
Reasons why there is a prevalence of insecure software:
|
1) Iron triangle constraints of time/schedule, resources/scope/people, and cost/budget
2) Security as an afterthought because of lack on return on security investment but cost of fixing issues early is low 3) Security versus usability as it may increase complexity, restrictiveness, but see psychological acceptability. |
|
|
Quality and security differ in
|
that security may lead to quality while the inverse may not be true. Trust the quality but validate security.
|
|
|
What makes software secure?
|
A profile consisting of Core, General, and Design Security Concepts
|
|
|
Core Security Concepts
|
Confidentiality, Integrity, Availability
|
|
|
General Security Concepts
|
Authentication, Authorization, Auditting/Logging, Session Management, Errors and Exception Management, Configuration Parameters Management
|
|
|
Design Security Concepts
|
Least Privilege, Separation of duties, Defense in depth, Fail secure, Economy of mechanism, Complete mediation, Open design, Least common mechanisms, Psychological acceptability, Leveraging existing components, Weakest link, Single point of failure
|
|
|
Do security concepts span across the entire SDLC?
|
Yes, it helps in risk management for example see NIST 800-64
|
|
|
Risk management in the context of software security is
|
the balancing act between the protection of IT assets and cost of implementing software security controls so that risk is handled properly. See NIST 800-30.
|
|
|
Define Asset
|
(In)tangile Items of value, the loss of which can cause disruptions in missions accomplishment.
|
|
|
Define Vulnerability
|
A weakness or flaw that could be exploited, resulting in security policy breaches across the SDLC (process, design, or implementation of a system).
|
|
|
Examples of process vulnerabilities
|
Improper source-code control, backups, access control.
|
|
|
Examples of design vulnerabilities
|
Using obsolete crypto algorithms such as DES, not handling resource deadlocks, unhandled exceptions, hard-coding db connections.
|
|
|
Examples of implementation vulnerabilities
|
Software accepts any user supplied data and processes it without first validating it; reveals too much information in the event of an error, not closing connections to backend dbs.
|
|
|
Some well-known vulnerability trackers and repositories
|
US-CERT, CVWW, OSVDB, CVE, CWE
|
|
|
Define Threat and its classes
|
A possible unwanted, unintended, or harmful event posed by vulnerabilities to assets in terms of disclosure, alteration, or destruction.
|
|
|
Define Threat Source / Agent
|
Anyone or anything that has the probability/likelihood to make a threat materialize.
|
|
|
Define Attack
|
When a source or agent materializes a threat
|
|
|
Define Probability
|
The likelihood that a particular threat can happen.
|
|
|
Define Impact
|
The extent of the disruptions to the organization's ability to achieve its goals
|
|
|
Define Exposure Factor
|
The opportunity for a threat to cause loss. A low exposure factor may reduce the overall risk of exploitation.
|
|
|
Define Controls
|
Technical, administrative, or physical mechanisms by which threats to software and systems can be mitigated.
|
|
|
Define Total Risk
|
The likelihood of attack in terms of asset value, threat, and vulnerabilities.
|
|
|
Define Residual Risk
|
The remaining risk after the implementation of mitigating security controls.
|
|
|
How is risk conventionally expressed?
|
As the product of the probability of a threat source/agent taking advantage of a vulnerability and the corresponding impact.
|
|
|
How is risk classically calculated?
|
Annual Loss Expectancy = SLE(Asset value x Exposure Factor) x ARO (threat occurrence expectation in a year)
|
|
|
What is the primary goal of risk management?
|
The identification and reduction of the total risk using controls so that the residual risk is within the acceptable range or threshold, wherein business operations are not disrupted.
|
|
|
The most effective way to ensure that software developed has taken into account security threats and addressed vulnerabilities, thereby reducing overall risk of that software.
|
Incorporate risk management processes into the SDLC itself.
|
|
|
Challenges to risk management for software:
|
* Still maturing
* Software asset values are often subjective * Limited data on the EF, Impact, and Probability of software security breaches * Technical security risk is only a portion of the overall state of secure software |
|
|
PCI DSS
|
Payment Card Industry Data Security Standard for the secure transmission and storage of credit card primary account number (PAN), etc.
|
|
|
Five possible ways to address risk (IAMAT):
|
1) Ignore the risk
2) Avoid the risk 3) Mitigate the risk 4) Accept the risk 5) Transfer the risk |
|
|
Summarize risk management concepts
|
1) Owners value assets and wish to minimize risk to assets
2) Threat agents wish to abuse or damage assets and give rise to threats that increase the risk to assets 3) Threats may exploit vulnerabilities leading to the risk to assets 4) When known, vulnerabilities may be reduced by implementing controls that reduce the risk to assets 5) Controls themselves may pose additional unforeseen vulnerabilities |
|
|
What is a security policy?
|
The what and why document. It specifies the assets that need to be protected and the possible repercussions of noncompliance. Also state's the organization's goals and objectives. Ensures nonrepudiation in the organization. Provides CIA guidance to architect secure software. May define the security team for incident responses, enforcement mechanisms, and for exception handling, rewards, discipline.
|
|
|
What may the scope be for an information security policy?
|
Organizational (global applicability) or functional (unit or specific issue applicability).
|
|
|
What are prerequisites for Security Policy Development?
|
1) Enforce-ability, top-level support
2) Inclusion of various teams 3) Marketing efforts that communicate mgmt goals |
|
|
Is security policy development a onetime activity?
|
No, the policy should be periodically evaluated so that they are contextually correct and relevant to address current-day threats.
|
|
|
High level security policies are supported by what?
|
More detailed security standards such as internal coding standards and external industry (PCI DSS), governmental (NIST), international (ISO), and national standards (FIPS).
|
|
|
Advantages attributable to using coding standards:
|
Consistency in style, improved readability, and maintainability (nonsecurity advantages). Less prone to errors and exposure to threats (security advantages).
|
|
|
What is PCI DSS?
|
Payment Card Industry Data Security Standard for the secure transmission and storage of credit card primary account number (PAN), etc.
|
|
|
PCI DSS control objectives
|
1) Build and maintain a secure network, 2) Protect cardholder data, 3) Maintain a vulnerability management program, 4) Implement strong access control, 5) Regularly monitor and test networks, 6) Maintain an information security policy
|
|
|
NIST's computer security division information technology laboratory (ITL) periodically publishes which special publications:
|
NIST Special Publication (SP) 500 and 800 series. NIST also publishes bulletins and computer security-related Federal Information Processing Standards (FIPS).
|
|
|
NIST SP which discusses security considerations in the information systems development lifecycle:
|
NIST SP 800-64
|
|
|
NIST SP "handbook" which discusses the benefits of different security controls and the scenarios in which they would be appropriately applicable:
|
NIST SP 800-12
|
|
|
NIST SP for generally accepted principle and practices for securing IT systems:
|
NIST SP 800-14
|
|
|
NIST SP risk management guide for IT
|
NIST SP 800-30
|
|
|
NIST SP for security considerations in the information systems development life cycle
|
NIST SP 800-64 (especially pertinent to CSSLPs)
|
|
|
NIST SP guide for managers in information security
|
NIST SP 800-100
|
|
|
What are ISO standards and what do they cover?
|
International Standards Organizations and they cover all sectors except electrotechnology (IEC) and telecommunications (ITU).
|
|
|
ISO/IEC standard for information security management system (ISMS) overviews and vocabulary:
|
ISO/IEC 27000:2009
|
|
|
ISO/IEC standard for information security management system (ISMS):
|
ISO/IEC 27001:2005
|
|
|
ISO/IEC standard for code of practice for information security management:
|
ISO/IEC 27002:2005/Cor1:2007
|
|
|
ISO/IEC standard concerning ISMS Implementation Guidance
|
ISO/IEC FCD 27003
|
|
|
ISO/IEC standard for information security risk management
|
ISO/IEC 27005:2008
|
|
|
ISO/IEC standard on requirements for bodies providing audit and certification of ISMS
|
ISO/IEC 27006:2007
|
|
|
ISO/IEC standard on evaluating criteria for IT security (Common Criteria)
|
ISO/IEC 15408, part1 introduces security functional and security assurance requirements (SFRs and SARs) along with the protection profile (PP), the security target (ST), and the target of evaluation (TOE). Part 2 contains the catalog of predefined SFRs as classes, families, and components. Part 3 defines the SARs and include the EALs for measuring assurance of a TOE.
|
|
|
CSSLP?
|
Certified Secure Software Lifecycle Professional
|
|
|
What approach does CSSLP take?
|
Holistic approach covering people, processes, and technology elements in developing software.
|
|
|
Seven domains of the CSSLP Common body of knowledge (CBK)
|
1) Secure Software Concepts
2) " Requirements 3) " Design 4) " Implementation/Coding 5) " Testing 6) " Acceptance 7) " Deployment, Operations, Maintenance, and Disposal |
|
|
Holistically secure software secures:
|
The network, hosts, and application layers so there is no weak link.
|
|
|
Reasons why there is a prevalence of insecure software:
|
1) Iron triangle constraints of time/schedule, resources/scope/people, and cost/budget
2) Security as an afterthought because of lack on return on security investment but cost of fixing issues early is low 3) Security versus usability as it may increase complexity, restrictiveness, but see psychological acceptability. |
|
|
Quality and security differ in
|
that security may lead to quality while the inverse may not be true. Trust the quality but validate security.
|
|
|
What makes software secure?
|
A profile consisting of Core, General, and Design Security Concepts
|
|
|
Core Security Concepts
|
Confidentiality, Integrity, Availability
|
|
|
General Security Concepts
|
Authentication, Authorization, Auditting/Logging, Session Management, Errors and Exception Management, Configuration Parameters Management
|
|
|
Design Security Concepts
|
Least Privilege, Separation of duties, Defense in depth, Fail secure, Economy of mechanism, Complete mediation, Open design, Least common mechanisms, Psychological acceptability, Leveraging existing components, Weakest link, Single point of failure
|
|
|
Do security concepts span across the entire SDLC?
|
Yes, it helps in risk management for example see NIST 800-64
|
|
|
Risk management in the context of software security is
|
the balancing act between the protection of IT assets and cost of implementing software security controls so that risk is handled properly. See NIST 800-30.
|
|
|
Define Asset
|
(In)tangile Items of value, the loss of which can cause disruptions in missions accomplishment.
|
|
|
Define Vulnerability
|
A weakness or flaw that could be exploited, resulting in security policy breaches across the SDLC (process, design, or implementation of a system).
|
|
|
Examples of process vulnerabilities
|
Improper source-code control, backups, access control.
|
|
|
Examples of design vulnerabilities
|
Using obsolete crypto algorithms such as DES, not handling resource deadlocks, unhandled exceptions, hard-coding db connections.
|
|
|
Examples of implementation vulnerabilities
|
Software accepts any user supplied data and processes it without first validating it; reveals too much information in the event of an error, not closing connections to backend dbs.
|
|
|
Some well-known vulnerability trackers and repositories
|
US-CERT, CVWW, OSVDB, CVE, CWE
|
|
|
Define Threat and its classes
|
A possible unwanted, unintended, or harmful event posed by vulnerabilities to assets in terms of disclosure, alteration, or destruction.
|
|
|
Define Threat Source / Agent
|
Anyone or anything that has the probability/likelihood to make a threat materialize.
|
|
|
Define Attack
|
When a source or agent materializes a threat
|
|
|
Define Probability
|
The likelihood that a particular threat can happen.
|
|
|
Define Impact
|
The extent of the disruptions to the organization's ability to achieve its goals
|
|
|
Define Exposure Factor
|
The opportunity for a threat to cause loss. A low exposure factor may reduce the overall risk of exploitation.
|
|
|
Define Controls
|
Technical, administrative, or physical mechanisms by which threats to software and systems can be mitigated.
|
|
|
Define Total Risk
|
The likelihood of attack in terms of asset value, threat, and vulnerabilities.
|
|
|
Define Residual Risk
|
The remaining risk after the implementation of mitigating security controls.
|
|
|
How is risk conventionally expressed?
|
As the product of the probability of a threat source/agent taking advantage of a vulnerability and the corresponding impact.
|
|
|
How is risk classically calculated?
|
Annual Loss Expectancy = SLE(Asset value x Exposure Factor) x ARO (threat occurrence expectation in a year)
|
|
|
What is the primary goal of risk management?
|
The identification and reduction of the total risk using controls so that the residual risk is within the acceptable range or threshold, wherein business operations are not disrupted.
|
|
|
The most effective way to ensure that software developed has taken into account security threats and addressed vulnerabilities, thereby reducing overall risk of that software.
|
Incorporate risk management processes into the SDLC itself.
|
|
|
Challenges to risk management for software:
|
* Still maturing
* Software asset values are often subjective * Limited data on the EF, Impact, and Probability of software security breaches * Technical security risk is only a portion of the overall state of secure software |
|
|
PCI DSS
|
Payment Card Industry Data Security Standard for the secure transmission and storage of credit card primary account number (PAN), etc.
|
|
|
Five possible ways to address risk (IAMAT):
|
1) Ignore the risk
2) Avoid the risk 3) Mitigate the risk 4) Accept the risk 5) Transfer the risk |
|
|
Summarize risk management concepts
|
1) Owners value assets and wish to minimize risk to assets
2) Threat agents wish to abuse or damage assets and give rise to threats that increase the risk to assets 3) Threats may exploit vulnerabilities leading to the risk to assets 4) When known, vulnerabilities may be reduced by implementing controls that reduce the risk to assets 5) Controls themselves may pose additional unforeseen vulnerabilities |
|
|
What is a security policy?
|
The what and why document. It specifies the assets that need to be protected and the possible repercussions of noncompliance. Also state's the organization's goals and objectives. Ensures nonrepudiation in the organization. Provides CIA guidance to architect secure software. May define the security team for incident responses, enforcement mechanisms, and for exception handling, rewards, discipline.
|
|
|
What may the scope be for an information security policy?
|
Organizational (global applicability) or functional (unit or specific issue applicability).
|
|
|
What are prerequisites for Security Policy Development?
|
1) Enforce-ability, top-level support
2) Inclusion of various teams 3) Marketing efforts that communicate mgmt goals |
|
|
Is security policy development a onetime activity?
|
No, the policy should be periodically evaluated so that they are contextually correct and relevant to address current-day threats.
|
|
|
High level security policies are supported by what?
|
More detailed security standards such as internal coding standards and external industry (PCI DSS), governmental (NIST), international (ISO), and national standards (FIPS).
|
|
|
Advantages attributable to using coding standards:
|
Consistency in style, improved readability, and maintainability (nonsecurity advantages). Less prone to errors and exposure to threats (security advantages).
|
|
|
What is PCI DSS?
|
Payment Card Industry Data Security Standard for the secure transmission and storage of credit card primary account number (PAN), etc.
|
|
|
PCI DSS control objectives
|
1) Build and maintain a secure network, 2) Protect cardholder data, 3) Maintain a vulnerability management program, 4) Implement strong access control, 5) Regularly monitor and test networks, 6) Maintain an information security policy
|
|
|
NIST's computer security division information technology laboratory (ITL) periodically publishes which special publications:
|
NIST Special Publication (SP) 500 and 800 series. NIST also publishes bulletins and computer security-related Federal Information Processing Standards (FIPS).
|
|
|
NIST SP which discusses security considerations in the information systems development lifecycle:
|
NIST SP 800-64
|
|
|
NIST SP "handbook" which discusses the benefits of different security controls and the scenarios in which they would be appropriately applicable:
|
NIST SP 800-12
|
|
|
NIST SP for generally accepted principle and practices for securing IT systems:
|
NIST SP 800-14
|
|
|
NIST SP risk management guide for IT
|
NIST SP 800-30
|
|
|
NIST SP for security considerations in the information systems development life cycle
|
NIST SP 800-64 (especially pertinent to CSSLPs)
|
|
|
NIST SP guide for managers in information security
|
NIST SP 800-100
|
|
|
What are ISO standards and what do they cover?
|
International Standards Organizations and they cover all sectors except electrotechnology (IEC) and telecommunications (ITU).
|
|
|
ISO/IEC standard for information security management system (ISMS) overviews and vocabulary:
|
ISO/IEC 27000:2009
|
|
|
ISO/IEC standard for information security management system (ISMS):
|
ISO/IEC 27001:2005
|
|
|
ISO/IEC standard for code of practice for information security management:
|
ISO/IEC 27002:2005/Cor1:2007
|
|
|
ISO/IEC standard concerning ISMS Implementation Guidance
|
ISO/IEC FCD 27003
|
|
|
ISO/IEC standard for information security risk management
|
ISO/IEC 27005:2008
|
|
|
ISO/IEC standard on requirements for bodies providing audit and certification of ISMS
|
ISO/IEC 27006:2007
|
|
|
ISO/IEC standard on evaluating criteria for IT security (Common Criteria)
|
ISO/IEC 15408, part1 introduces security functional and security assurance requirements (SFRs and SARs) along with the protection profile (PP), the security target (ST), and the target of evaluation (TOE). Part 2 contains the catalog of predefined SFRs as classes, families, and components. Part 3 defines the SARs and include the EALs for measuring assurance of a TOE.
|
|
|
ISO/IEC standard on System Security Engineering Capability Maturity Model (SSE-CMM)
|
ISO/IEC 21827:2008 provides guidelines to ensure secure engineering of system and software by augmenting project and organizational process areas and encompassing all phases in the SDLC from definitions, requirement analysis, design, development, testing, deployment, operations, maintenance, and disoposal.
|
|
|
ISO/IEC Software Engineering Product Quality standard
|
ISO/IEC 9216 provides for quality of software products.
|
|
|
Aside from SPs what other publications does NIST produce?
|
Federal Information Processing Standards (FIPS) which address requirements for 1) Interoperability of disparate systems, 2) Portability of data and software, 3) Computer security
|
|
|
FIPS publication on Security Requirement for Cryptographic Modules
|
FIPS 140-2 which includes cryptographic module specification, ports and interfaces, roles, services, authentication, finite state model, physical security, operation environment, cryptographic key management, electromagentic interference/compatibility (EMI/EMC), self-tests, and design assurance. Also requires documentation on control to mitigate other attacks (power analysis TEMPEST).
|
|
|
FIPS publication on Advance Encryption Standards (AES)
|
FIPS 197 defines the AES, a symmetic block cipher.
|
|
|
FIPS publication on Personal Identity Verification (PIV) of Federal Employees and Contractors
|
FIPS 201 as a response to the need to ensure that the trust of claimed identities.
|
|
|
Benefits of Security Standards:
|
Provides a common and consistent basis for building and maintaining secure software as they enable operational efficiency and agility; Interoperability; Competitive advantage; A common baseline for assessments; For demonstrating indirect governance.
|
|
|
Security Best practices or de facto security standards:
|
Open Web Application Security Project (OWASP) (Development, Code Review, and Testing Guides), Information Technology Infrastructure Library (ITIL) (for service management)
|
|
|
Security Methodologies that can be used throughout the SDLC
|
Socratic; Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE); STRIDE and DREAD; Open Source Security Testing Methodology Manual (OSSTMM); Flaw Hypothesis Method (FHM); Six Sigma; Capability Maturity Model Integration (CMM)
|
|
|
STRIDE and DREAD
|
Threat Modeling Methodology: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service; Elevation of privilege; and Damage Potential Reproducibility; Exploitability; Affected users; Discoverability.
|
|
|
Comprehensive penetration testing methodology
|
Flaw Hypothesis Method
|
|
|
Business management strategy for quality that can be used for security
|
Six Sigma because it measures deviations from the specified norm.
|
|
|
A process improvement methodology applicable to security
|
Capability Maturity Model Integration (CMMI) with 5 level of Initial, Repeatable, Defined, Managed Quantitatively, Optimizing
|
|
|
Prominent security frameworks related with software security
|
Zachman Framework (6x6 matrix of roles versus interrogatives); Control Objectives for Information and Related Technology (COBIT); Committee of Sponsoring Organizations (COSO); Sherwood Applied Business Security Architecture (SABSA)
|
|
|
Importance of regulations, privacy and compliance
|
For providing a check and balance mechanism to earn stakeholder trust and prevent disclosures of PII, PHI, PFI.
|
|
|
Significant regulations and acts on software security
|
Sarbanes-Oxley (SOX) Act for improving quality and transparency in financial reporting, independent audits and accounting; BASEL II (Euro regs to protect against financial risks and fraud); Gramm-Leach-Bliley Act (GLBA) for financial data (PFI) privacy; Health Insurance Portability and Accountability Act (HIPPA); Data Protection Act; Computer Misuse Act; State Security Breach Laws.
|
|
|
Challenges with Regulations and Privacy Mandates
|
Open interpretations, auditor's subjectivity, localized jurisdiction, regional variations, and inconsistent enforcement
|
|
|
Best practices for addressing privacy in software development
|
Collect only what's needed; Informed consent via Acceptable Use Policy (AUP); Process, store, archive collected data only if needed
|
|
|
Security Models
|
Confidentiality (Bell-LaPadula); Integrity Models (Biba, Clark and Wilson); Access Control Models (Brewer and Nash)
|
|
|
Trusted Computing Concepts
|
Ring Protection; Trust Boundary (Security Perimeter); Trusted Computing Base (TCB), Reference Monitor, and Rootkits (TC threat).
|
|
|
A specification to ensure protection and implementations against disclosure of sensitive and private information
|
Trusted Platform Module (TPM)
|
|
|
The primary reason for incorporating security into the software development life cycle is to protect:
|
Corporate brand and reputation
|
|
|
The resiliency of software to withstand attacks that attempt to modify or alter data in an unauthorized manner is referred to as:
|
Integrity
|
|
|
The main reason as to why the availability aspects of software must be part of the organization's software security initiative is:
|
Software issues can cause downtime to the business
|
|
|
Monitoring software functionality and report when software is down is a protection to assure:
|
Availability
|
|
|
Authentication of the type that requires one to enter a number that is used only once (nonce) from a token device issued by a service provider:
|
Ownership-based
|
|
|
Multifactor authentication is most closely related to which security design principle:
|
Defense in depth
|
|
|
Audit logs can be used for:
|
Providing evidentiary information; Non-repudiation; Detecting the actions that were undertaken; But does not prevent a user from performing some unauthorized operation.
|
|
|
Impersonation attacks such as man-in-the-middle (MITM) attacks in an Internet application can be best mitigated using proper:
|
Session management
|
|
|
Organizations often predetermine the acceptable number of user errors before recording them as security violations. This number is otherwise known as:
|
Clipping level
|
