Full Study Material for ISTQB – Foundation & All 3 Advanced level Certification Exams
I am bringing to you Full-Fledged Crash Courses cum Self Learn Study Material for ISTQB Foundation Level as well as Advanced CTAL level exams for Test Managers, Test Analysts & Technical Test Analysts exams.
Use the following link to access the new study material for All 4 types of ISTQB Certification exams.
ISTQB Foundation Level Exam- (Crash Course & Study Material)
- Quickstart to ISTQB Foundation Exam - Key Questions Answered
- ISTQB Foundation Exam - Full Crash Course (Set of 30 Parts)
- ISTQB Foundation Exam - K-Level wise Special Questions with Explanation (Set of 60 Questions)
Largest Database of Sample Papers - 750 Unique Questions for Practice Just before the Exam
- ISTQB Certification Preparation Help Guide
- Practical Roadmap to ISTQB Certification
- Twelve Top Questions about ISTQB Certification
ISTQB Advanced CTAL Test Manager Exams (Crash Course & Study Material)
- Quickstart to ISTQB CTAL Test Managers Exam - Key Questions Answered
- K Level Wise Topics CTAL Test Managers Exam as per the CTAL Syllabus
- CTAL Test Managers Exam Sample Papers Set of 70 Questions
- Set of 120 Descriptive Question / Answers and Preparatory Articles
- Consolidated Crash Course for CTAL Test Managers Exam
ISTQB Advanced CTAL Test Analyst & Technical Analyst Exams (Crash Course & Study Material)
- Quickstart to ISTQB CTAL Test Analysts Exam - Key Questions Answered
- K Level Wise Topics CTAL Test Analysts Exam as per the CTAL Syllabus
- K Level Wise Topics CTAL Technical Test Analysts Exam as per the CTAl Syllabus
- CTAL Test Managers Exam Sample Papers Set of 80 Questions
- Study Guides (Set of 8) & Preparatory Articles
- Consolidated Crash Course for CTAL Test Analysts Exam
Security in Software Testing and Introduction to Security Development Lifecycle
Security in Software Testing and Introduction to Security Development Lifecycle
Software Development Life Cycle, Software Testing Life Cycle & Security-Testing Life Cycles are methodologies well known across the IT industry. Let us try to know about a sparingly known methodology - Security Development Lifecycle or SDL
Security Development Lifecycle is an innovative methodology brought by Microsoft & IBM in the year 2002. This is a process wherein every security issue is made a priority during every stage of the software development process.
The SDL introduces the use of several techniques like threat modeling, use of static analysis tools, code reviews, and a final review of security into a structured process that can reduce the number of security vulnerabilities found after system shipment.
Following are the 4 - Principles in the Security Development Lifecycle.
Principle-1: Ensure Security by Designing
The system has to be designed from the start to protect both itself and all information processed by it, as well as to be resistant to attacks. This design has to be carried out through implementation as well.
Principle-2: Ensure Security by Default
The default state of the system should minimize the possible risks when attacks (successful or unsuccessful) take place. This includes items such as running at least access, turning off features not needed by the majority of users, etc.
Principle-3: Ensure Security while Deployment
The software needs to be shipped with documentation and manuals that will help the end users as well as the administrators install and use the software securely. Secondly the installation of all updates must be easy.
Principle-4: Communications
There must be open and responsible communication with consumers when product vulnerabilities are found, in order to keep both the end users as well as the administrators aware of how to take proactive measures to protect themselves.
In addition to the preceding four main principles, the SDL lays out the security tasks that need to take place at each step in the traditional software development life cycle.
Probably, the key aspect to the success of any attempt to adopt SDL is education - a lot of education. Most people (in all disciplines) do not come to a project already completely educated on what they need to do to insure an effective and comprehensive job of implementing SDL. An educational effort needs to be put in place, both at the beginning of SDL adoption and on an ongoing basis. This can be an in-house or a contract effort, or even a mix, according to the needs & the size of your organization.
Following figure represents a graphical representation of a typical SDL.
(A) Security in Requirements Defining Phase
The first thing to be done at this stage is to determine a person who will be the single window contact, advisor, and resource as the release goes through the stages of SDL to release. This person must have the training and experience sufficient enough to lead and guide the project and its team. Such a person assists in reviewing the plans, making useful recommendations, & insuring any required resources or training are received by the team.
During the requirements phase, the following decisions are made:
1) How security shall be integrated with the process of development?
2) What are the main objectives of security?
3) How can security be maximized with disruption remaining minimized?
4) What software is likely to be used with the system under development, and how security related features will be integrated with that other software?
5) What security feature requirements are needed for the system under development? Though some of these are discovered later (when threat analysis is done), this is the time when the features determined by customer request, certification requirements, or regulatory requirements are considered.
All these steps should be taken into account and addressed at the same time the new feature and other requirements are being collected.
(B) Security in Designing Phase
During this phase in the software development life cycle, the overall plan and architecture for the system is created. As the project goes through this stage, the SDL focus remains on the following.
a) Defining the designing guidelines & architecture of security:
It includes determining what functions are integral to security as well as what design techniques apply to a project globally. Basically it involves the creation of an overall security design.
b) Documenting the elements of the surface of software attacks:
By default, which features get automatically exposed to the users?
What is the minimum possible privilege level for these features?
It is very important to find any place where the attack surface is increased and question it every time.
c) Conducting the threat modeling:
This should be done at a component level. There are several methods of threat modeling that can be used, each with its own focus and take on the process, but the intent is still to come away with a prioritized list of threats that must be mitigated, In addition the areas that should receive careful examination to insure that those areas function properly.
d) Defining Supplemental Criteria for Shipping:
This can include criteria such as the beta testing being security bug-free or having passed a security bug bash.
(C) Security in Implementation Phase
During this phase, coding and integration are performed. Note that, in the Microsoft version of the SDL, this is when the formal testing is conducted, but testing should (and usually does) continue all the way through until the system is actually shipped. Any steps that can be taken in this phase to prevent or eliminate security defects are very inexpensive, and they drastically reduce the chance that these flaws will migrate to your final system.
In the SDL, the following steps are implemented:
# Use standards for coding & testing.
# Use fuzzing tools & relevant tools for security-testing.
# Use tools for code scanning / static analysis.
# Carry out code reviews.
(D) Security in Verification Phase
This is the phase in which the features are code complete and testing (include beta testing) is being conducted. In the SDL, this is the time that more stringent code reviews & a specific security test pass are conducted. It allows review & testing of not only the new or modified code but also the unmodified legacy code of the release phase.
(E) Security in Release Phase
The release phase in the SDL is when the system is put through "Final Security Review" (FSR). This review is designed to answer the question of whether the system is now ready to be released to the customers with a security standpoint. The stated ideal is to have the FSR conducted 2-6 months before the system is to be released, both to insure that the FSR is conducted on code that is as mature as possible and as least likely to be changed. Of course, this depends heavily on the release schedule of the system, and the move to faster and more nimble release schedules makes this timeline an almost unattainable goal in many cases.
The "Final Security Review" is intended to be conducted by an independent team, and sometimes even by outside security review consultants. This is to try to isolate the FSR from preconceptions and biases that exist on the product design team as much as possible.
(F) Security in Support and Servicing
There is no way to ship a system that is 100 percent bug free, so there has to be a way to respond to newly discovered vulnerabilities. This process includes a way to evaluate reports of new vulnerabilities and issue fixes as needed.
The other thing that needs to occur during this part of the SDL is a postmortem assessment and analysis of the security bugs found. How, where, and when they were found may indicate a need for process change, a need for tool updates or changes, etc.
Software Development Life Cycle, Software Testing Life Cycle & Security-Testing Life Cycles are methodologies well known across the IT industry. Let us try to know about a sparingly known methodology - Security Development Lifecycle or SDL
Security Development Lifecycle is an innovative methodology brought by Microsoft & IBM in the year 2002. This is a process wherein every security issue is made a priority during every stage of the software development process.
The SDL introduces the use of several techniques like threat modeling, use of static analysis tools, code reviews, and a final review of security into a structured process that can reduce the number of security vulnerabilities found after system shipment.
Following are the 4 - Principles in the Security Development Lifecycle.
Principle-1: Ensure Security by Designing
The system has to be designed from the start to protect both itself and all information processed by it, as well as to be resistant to attacks. This design has to be carried out through implementation as well.
Principle-2: Ensure Security by Default
The default state of the system should minimize the possible risks when attacks (successful or unsuccessful) take place. This includes items such as running at least access, turning off features not needed by the majority of users, etc.
Principle-3: Ensure Security while Deployment
The software needs to be shipped with documentation and manuals that will help the end users as well as the administrators install and use the software securely. Secondly the installation of all updates must be easy.
Principle-4: Communications
There must be open and responsible communication with consumers when product vulnerabilities are found, in order to keep both the end users as well as the administrators aware of how to take proactive measures to protect themselves.
In addition to the preceding four main principles, the SDL lays out the security tasks that need to take place at each step in the traditional software development life cycle.
Probably, the key aspect to the success of any attempt to adopt SDL is education - a lot of education. Most people (in all disciplines) do not come to a project already completely educated on what they need to do to insure an effective and comprehensive job of implementing SDL. An educational effort needs to be put in place, both at the beginning of SDL adoption and on an ongoing basis. This can be an in-house or a contract effort, or even a mix, according to the needs & the size of your organization.
Following figure represents a graphical representation of a typical SDL.
(A) Security in Requirements Defining Phase
The first thing to be done at this stage is to determine a person who will be the single window contact, advisor, and resource as the release goes through the stages of SDL to release. This person must have the training and experience sufficient enough to lead and guide the project and its team. Such a person assists in reviewing the plans, making useful recommendations, & insuring any required resources or training are received by the team.
During the requirements phase, the following decisions are made:
1) How security shall be integrated with the process of development?
2) What are the main objectives of security?
3) How can security be maximized with disruption remaining minimized?
4) What software is likely to be used with the system under development, and how security related features will be integrated with that other software?
5) What security feature requirements are needed for the system under development? Though some of these are discovered later (when threat analysis is done), this is the time when the features determined by customer request, certification requirements, or regulatory requirements are considered.
All these steps should be taken into account and addressed at the same time the new feature and other requirements are being collected.
(B) Security in Designing Phase
During this phase in the software development life cycle, the overall plan and architecture for the system is created. As the project goes through this stage, the SDL focus remains on the following.
a) Defining the designing guidelines & architecture of security:
It includes determining what functions are integral to security as well as what design techniques apply to a project globally. Basically it involves the creation of an overall security design.
b) Documenting the elements of the surface of software attacks:
By default, which features get automatically exposed to the users?
What is the minimum possible privilege level for these features?
It is very important to find any place where the attack surface is increased and question it every time.
c) Conducting the threat modeling:
This should be done at a component level. There are several methods of threat modeling that can be used, each with its own focus and take on the process, but the intent is still to come away with a prioritized list of threats that must be mitigated, In addition the areas that should receive careful examination to insure that those areas function properly.
d) Defining Supplemental Criteria for Shipping:
This can include criteria such as the beta testing being security bug-free or having passed a security bug bash.
(C) Security in Implementation Phase
During this phase, coding and integration are performed. Note that, in the Microsoft version of the SDL, this is when the formal testing is conducted, but testing should (and usually does) continue all the way through until the system is actually shipped. Any steps that can be taken in this phase to prevent or eliminate security defects are very inexpensive, and they drastically reduce the chance that these flaws will migrate to your final system.
In the SDL, the following steps are implemented:
# Use standards for coding & testing.
# Use fuzzing tools & relevant tools for security-testing.
# Use tools for code scanning / static analysis.
# Carry out code reviews.
(D) Security in Verification Phase
This is the phase in which the features are code complete and testing (include beta testing) is being conducted. In the SDL, this is the time that more stringent code reviews & a specific security test pass are conducted. It allows review & testing of not only the new or modified code but also the unmodified legacy code of the release phase.
(E) Security in Release Phase
The release phase in the SDL is when the system is put through "Final Security Review" (FSR). This review is designed to answer the question of whether the system is now ready to be released to the customers with a security standpoint. The stated ideal is to have the FSR conducted 2-6 months before the system is to be released, both to insure that the FSR is conducted on code that is as mature as possible and as least likely to be changed. Of course, this depends heavily on the release schedule of the system, and the move to faster and more nimble release schedules makes this timeline an almost unattainable goal in many cases.
The "Final Security Review" is intended to be conducted by an independent team, and sometimes even by outside security review consultants. This is to try to isolate the FSR from preconceptions and biases that exist on the product design team as much as possible.
(F) Security in Support and Servicing
There is no way to ship a system that is 100 percent bug free, so there has to be a way to respond to newly discovered vulnerabilities. This process includes a way to evaluate reports of new vulnerabilities and issue fixes as needed.
The other thing that needs to occur during this part of the SDL is a postmortem assessment and analysis of the security bugs found. How, where, and when they were found may indicate a need for process change, a need for tool updates or changes, etc.
Subscribe to:
Posts (Atom)