- 1. Development Methodologies
- 2. Maturity Models
- 3. Operation, Maintenance and Change Management
- 4. DevOps
- 5. Code Repositories
- 6. Third Party Code
- 7. Code Signing
- 8. Database Security Controls
- 9. Software Testing
- 10. Code Reviews
- 11. Code Tests
- 12. Fuzz Testing (Fuzzing)
- 13. Code Execution
1. Development Methodologies
This is the first SDLC developed in the 1970’s by Winston Royce. The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap
This approach does allow for movement back to an earlier step, but only one phase at a time. EG: if software fails in the testing phase, it goes back to the code and debug phase for more testing. This process is very rigid and doesn’t allow for many changes to the software while development is in place.
If a business unit identifies a desirable new feature halfway through the coding process, there is no opportunity to modify the design. Because of this, there aren’t many modern software development shops that embrace the Waterfall model.
This was designed in the 1980’s by Barry Boehm. The Spiral Model has four phases, a software development project repeatedly passes through these phase in iterations called Spirals.
Agile SDLC model is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break the product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves cross functional teams working simultaneously on various areas.
2. Maturity Models
Maturity models provide a way for an organisation to evaluate themselves against a standard benchmark and identify the next steps in evolving their software development practices.
Software Capability Maturity Model (SW CCM)
This helps the organisation identify where they are in the maturity model. It consists of 5 different levels:
Level 1 – Initial: disorganised approach to software development. Good intentions but not following sound engineering practices.
Level 2 – Repeatable: Some key activities that happen at this stage:
– Requirements management
– Software project planning
– Software project tracking and oversight
– Subcontract management
– Quality assurance
– Configuration Management
In this phase, the organization might have some basic processes such as reusing code between projects.
Level 3 – Defined: at this stage they have formal documented practices they follow for software development. Some activities that happen at this stage-
– Organisation process focus
– Process definition
– Training programs
– Integrated management
– Software engineering
– Intergroup coordination
– Peer reviews
Level 4 – Managed: This uses quantitative measures to evaluate their progress and understand the effectiveness of their practices.
Level 5 – Optimising: This using continuous process improvements to strive to always get better.
IDEAL serves as a kind of roadmap for initiating, planning, and implementing process improvement actions. It is a process-improvement and defect-reduction methodology.
The IDEAL model is named for the five phases an organisation runs through in performing a change initiative: Initiating, Diagnosing, Establishing, Acting, Learning.
Initiating — Lay the groundwork for a successful improvement effort:
Typically the Initiating phase is the direct response of some stimulus showing a need of urgency to change the current way of doing business. In return to this stimulus, the appropriate sponsorship is established, and the appropriate resources are allocated.
Diagnosing — Determine where you are relative to where you want to be:
In the Diagnosing phase, a kind of analysis is performed to baseline the current practices and to probe potential improvement opportunities. For the CMMI Product Suite this is a SCAMP Appraisal, for ISO 15504 an assessment.
Establishing — Plan the specifics of how you will reach the objectives:
In the Establishing phase, the recommendations of the analysis are prioritized, change implementation teams are established, and plans are developed to conduct the activities.
Acting — Do the work according to the plan:
In the Acting phase, the planned activities are implemented.
Learning — Learn from the experience and improve the ability to adopt new improvements in the future:
During the Learning phase lessons learned are collected that can then be applied to subsequent rounds of the IDEAL change cycle.
3. Operation, Maintenance and Change Management
Once software is developed is moves into this phase. During this phase, organisations should follow standard change management procedures that avoid unnecessary disruptions and control the flow of code to production. Software is never finished. Once the development process has concluded, the organisation is still responsible for maintaining that code until it is decommissioned. If a software is developed for internal use the developers will likely have requests from internal customers to fix bugs, add enhancements etc… If the software is for external customers they will more likely be more demanding with their requests.
This is one of the most important processes an organisation must put in place. This should consist of 3 key elements:
- Request control:
– customers place requests for modifications
– managers receive the requests and estimate the cost and benefits of implementing it
- Change control: this grants permissions for the developers to make changes to the code. The manager (or developer) writes an RFC (Request for change) which explains the intended change. This gets reviewed and then the developer may get the permission to make the changes.
- Release Control: After the developer has made the changes they put in into a release management process. During this stage the quality assurance team tests the code and verifies it meets the requirements. After receiving quality assurance approval, a release manager moves the code into production.
This merges two worlds: Software Development and IT Operations.
Software developers are responsible for writing the code, building the applications and integrations that meet the requirements of the customers and business. Developers need to rapidly release code to meet these demands.
IT Operations staff are responsible for maintaining the infrastructure and keeping the IT environment stable. They are often wary of change because change brings the possibility of instability.
The DevOps movement seeks to bring these tow disciplines together in a partnership.
- build collaborative relationships between developers and operators with open communications
- embraces automation as an enabler of both development and operations
- facilitate the rapid release of new code
- offer stable environment
Infrastructure as Code (IaC)
IaC is the process of replacing manual processes and standard operating procedures to configure hardware devices and Operating Systems with scripts/code/applications that will automatically manage and provision the hardware and OS. IT is also known as Software Defined Infrastructure.
- Increases scalability
- Speed – it is much faster to setup and configure infrastructure
- reduces user error through automation and scripts
- facilitates testing of new code be being able to spin up a test environment quite easily
5. Code Repositories
The main purpose of a code repository is to store the source files used in software development in a centralised location that allows for secure storage and the coordination of changes among multiple developers. They also provide version control allowing the tracking of changes and rollback of code to previous versions.
Code repositories also meet the needs of security and auditing professionals who want to ensure that software development includes automated auditing and logging of changes.
Code repositories promote code reuse. Developers seeking code to perform a particular function can search the repository for existing code and then reuse it rather than starting from ground zero.
Code repositories also help avoid the problem of dead code where code is in use in an organisation, but nobody is responsible for the maintenance of that code, and in fact, nobody may even know where the original source files reside.
6. Third Party Code
Developers often depend on code created by someone else to improve their efficiency. This can be code created by someone else in their organisation or from external third parties.
These consist of shared code objects and their related functions. Instead of having to write the code to perform every details function, developers can simply locate libraries that contain the relevant functions and then call those functions.
Software Development Kits (SDKs)
These are collections of software libraries combined with documentation, examples and other resources designed to help programmers get up and running quickly in a development environment.
The following page is the Facebook SDK for iOS development: https://developers.facebook.com/docs/ios/
It includes a guide, getting started instructions and documentation. There are a wide variety of functions to help developers use Facebook login, let people log into applications using only their phone number, help people share things and send messages on Facebook.
Application Programming Interfaces (APIs)
This is a way of making services available to developers (that didn’t develop the software) instead of providing them with the actual code. EG: Twitter offers an API that allows developers to interact with the Twitter service.
7. Code Signing
Code signing provides a way for developers to demonstrate to end users that the applications are from a legitimate source. Digital signatures may be used for code signing.
- Developer obtains a digital certificate from a trusted certificate authority
- They then use their private key associated with that digital certificate to create a digital signature before releasing their code to the world
Verifying Code Signatures
- User downloads the code
- The OS uses the certificates public key to validate the signature
- The OS verifies the signature hash matches the code
- The OS verifies that the developer is trusted
8. Database Security Controls
This is a set of design principles that database designers should follow when building and modifying databases. Databases that follow these principles are set to be in normal forms.
- Prevent data inconsistency
- Prevent update anomalies
- Reduce the need for restructuring existing databases
- Make the database schema more informative
Exam tip: you should know the general idea of normal forms
- First Normal Form (1NF)
– create separate tables for different sets of related data
– provide a primary key for every table
– records may not have multi valued fields
– records in a table must have a same number of fields
- Second Normal Form (2NF)
– the table must be in 1NF (have all the requirements of the first normal form)
– every non-key field must be a fact about the entire key
- Third Normal Form (3NF)
– the table must be in 2NF (have all the requirements of the second normal form)
Information at rest in a database should be protected with strong encryption. This prevents someone with access to the database table from reading the sensitive information stored in that table unless they also have access to the corresponding encryption key. Encryption also helps prevent accidental data exposure cases, when database contents are inadvertently disclosed to unauthorized individuals.
Obfuscation & Camouflage
It is good practice not to name your database server “Credit Card Database” or something like that. Use a little strategy in your naming convention and don’t point attackers directly at your sensitive information.
Stored Procedures store the text of query on the database server and then allow applications to simply provide the arguments instead of the entire SQL command. If implemented correctly, stored procedures are an effective control against SQL injection attacks.
9. Software Testing
There are 2 main activities that happen in software testing:
- Software Validation: this answers the question “Are we building the right software?”. This ensures it meets the original building requirements.
- Software Verification: this answers the question ” Are we building the software right?” . This occurs throughout the development process and consists of tests to verify the software functions properly.
Stress Testing (Load Testing)
These tests simulate real world activity on the software
– Uses automated scripts to verify system capacity
– May be run internally or through a vendor
– Verifies the system can handle the maximum load expected
– Determines the maximum capacity of the system ( by stressing it until it fails)
User Acceptance Testing (UAT)
This is the final phase in software testing. This is commonly referred to as Beta testing. Once developers are confident that the software is correct and ready to move to production, they turn it over to end users for their evaluation under real world circumstances. This is usually done in a testing environment where users are asked to simulate real world transactions without actually altering production data.
After code is released developers often make minor and major changes to fix bugs discovered and add new functionality. Before releasing these modifications they conduct regression testing to verify there are no unintended side effects.
10. Code Reviews
During a code review, developers have their work reviewed by other developers who examine the code to ensure that it does not contain obvious or subtle security issues. This can be formal, informal or somewhere in between.
This is a formal code review process –
- Planning: preparing the materials required for the review, identifying the review participants and scheduling the actual review.
- Overview: assigning roles to participants and providing overview of the software
- Preparation: participants review the code independently to get ready for the review meeting. They look for potential issues and make notes.
- Meeting: developers meet and discuss any issues they have found.
- Rework: developers correct any defects identified during inspection. If there are significant changes to be made the process returns to the planning stage
- Follow up: the leader confirms that all defects have been rectified and signs off on the documentation
Most organisations use a less formal review process
11. Code Tests
Code tests verify that software ins functioning properly. It often uses technology in the code inspection process.
2. types of code testing:
- Static tests: the doesn’t actually get executed during a static test. Automated techniques are used to analyse the code for errors and security flaws
- Dynamic testing: in this test the code is executed and the results are verified to ensure the code is functioning correctly with no security flaws. This is the closest test to real world operations.
Synthetic transactions are scripted sets of inputs and instructions that are given to code when the testers know what output the code should produce for each input.
Testing software can automatically cycle through these synthetic transactions to verify that the code is functioning properly across a wide variety of tests.
EXAM TIPS: code reviews, static testing, dynamic testing are complimentary to one another. They are not competitors. They each have a different function.
12. Fuzz Testing (Fuzzing)
Fuzzing is a software testing technique that feeds software many different input values in an attempt to cause an unpredictable state (crash the software) or unauthorised access (disclose confidential information).
Fuzzing Input Sources
- Developer running the test can supply list of input values
- Developer can write a script that generates input values
- The fuzz testing software can generate input randomly or to specification (Generation Fuzzing)
- Fuzz tester can analyse real input and then modify those values (mutation fuzzing)
13. Code Execution
There are 2 main methods for executing code:
- Interpreted code: the computer reads the actual instructions written by developers as it executes the code. EG: R, Perl, PHP, VBScript
- Compiled code: the developer runs a compiler to convert source code to an executable fiel written in machine language. When a user wants to run the program, they the launch the executable file rather than the programmers original source code. EG: C, C++, Java, Julia and Fortran