8.1 Understand and integrate security in the Software Development Life Cycle (SDLC)

Development methodologies (Agile, Waterfall, DevOps, DevSecOps)
Maturity models (Capability Maturity Model (CMM), Software Assurance Maturity Model (SAMM))
Operation and maintenance
Change management
Integrated Product Team (IPT)

When we develop software, we must think about security at each stage of the development.

A computer understands only one language – machine code. Yet there are many languages. We choose the language we want to write in, and then we run the code through a compiler. The compiler converts our code to machine code. It is difficult or impossible to reverse engineer the machine code and bring back the original code.

Some languages are interpreted. They do not need to be compiled. Languages that are interpreted run within another program, called an interpreter. It is easy to read the interpreted language because it is available in plain text. There are some measures to protect the interpreted language from unauthorized access.

We want to protect our source code for three reasons

It is a trade secret
A hacker could read the source code and manipulate the output of the source code
A hacker could read the source code and identify vulnerabilities, which he can later exploit

When we build the software, we have to follow a lifecycle process. We must balance Security, Functionality, and User Friendliness.

The Software Lifecycle Process

Conceptual Definition – we need to think about what the software is going to do. At any other phase, we can go back to the conceptual definition to make sure we are still on track.
Functional Definition – we need to think about exactly how the system will work to meet the concepts. This way, we can break the project down into tasks.
- Inputs – what are the inputs to the program. What data will it accept? What data do users enter? What data does it collect automatically?
- Behavior – how will the program apply logic to these inputs?
- Outputs – what data will the program deliver? Where does it deliver the data? Does it output it to the screen, send an e-mail, update a database, or generate a file?
Control Specifications – how can we make sure that we develop a secure program? How can we make sure that the program is secure even during development – that nobody sneaks a back door into the source code? We need to make sure that only authorized individuals have access to the system and that they keep everything confidential.
Design Review – we review the concepts and functions to make sure that they make sense. We must review the program with the people who will be buying or using it to make sure that they are still in agreement
Code Review – we write the code. During the code writing process, we must review it regularly to make sure that it still makes sense, especially when there are multiple people working on it.
User Acceptance Testing – we have finished developing the software. Users need to start testing to make sure that the program does what they want it to do. If the program doesn’t work as expected, we must rewrite some parts of it.
Maintenance – maintenance means we need to make changes to the code. There should always be support because users will need to make changes. They will want to add or remove features.

Lifecycle Models

There are different ways to model the lifecycle.

Waterfall Model of Software Development – this model is one of the oldest. We move from one phase to the next in order.
- The phases
  - System Requirements – we identify what type of machine will run our software
  - Software Requirements – we identify what the software will do
  - Preliminary Design – we create a rough outline of what the software code will look like
  - Detailed Design – we create a detailed design based on the preliminary design
  - Code and Debug – we start writing source code and debugging it
  - Testing – we test the software. There may be multiple tests.
  - Operations and Maintenance – we continue to maintain the software based on user feedback.
- The model allows us to perform testing at the end of each phase. We don’t like this model anymore because it takes a long time to get from the planning phase to the testing phase. It might take years. By the time we create a working product, the original requirements are no longer relevant, and users want something else.
Spiral Model – it is like the waterfall model, but we move through phases multiple times. We apply the phases and then go back to the beginning.
Agile Model
- The Agile Software development process allows us to release incremental updates on a regular basis. Every two weeks or so, users receive a small update. We gather their feedback, prioritize the features that they have requested, spend a couple of weeks developing as many of them as possible, and release another update.
- 12 Principles of the Agile Manifesto
  - Customer satisfaction by early and continuous delivery of valuable software.
  - Welcome changing requirements, even in late development.
  - Deliver working software frequently (weeks rather than months)
  - Close, daily cooperation between business people and developers
  - Projects are built around motivated individuals, who should be trusted
  - Face-to-face conversation is the best form of communication (co-location)
  - Working software is the primary measure of progress
  - Sustainable development, able to maintain a constant pace
  - Continuous attention to technical excellence and good design
  - Simplicity—the art of maximizing the amount of work not done—is essential
  - Best architectures, requirements, and designs emerge from self-organizing teams
  - Regularly, the team reflects on how to become more effective, and adjusts accordingly
- The Agile Model has been adopted by some other models, which expand upon its original principles
  - Extreme Programming
    - There are four important processes – coding, testing, listening, and designing
    - The only important product is good code
    - We must perform a lot of testing to make sure that the software works as intended
    - We must listen to what the customer wants
    - We must have a good design. We want to reduce the interdependencies within the system.
  - Test Driven Development
    - After we develop the software requirements, we convert them into test cases. We build the software, and then we measure it against the test cases.
    - The process
      - We create a test based on the specifications. We want to create the test before we start writing the code. This way, we know that the code we are writing will meet the requirements of the test.
      - We run the test. The test must fail because we haven’t written any code yet. If the test doesn’t fail, that means that our software already meets the specifications, and we don’t need to make any changes.
      - We write code that passes the test. The code should be as simple as possible.
      - We run the test. If the test does not pass, then we must revise the code until the test passes.
      - We refactor the code – we improve its readability and efficiency.
    - The process is repeated until all of the functionality has been incorporated into the software. Every test should be small. That way, we can quickly go back and undo any changes if required.
  - Scrum
    - There are three parties
      - We have a product owner who represents the customer. The product owner decides what the product will look like from a business perspective. The product owner acts as a liaison between the development team and the business.
      - Developers write the software
      - The Scrum Master leads the development team. He might help define the changes for the product, provide coaching and education, and maintain the product backlog.
    - The Sprint
      - The sprint is an iteration. The normal length is two weeks.
      - At the start of the sprint, we have a planning event. We make a list of the items that we want to incorporate into the software. This is known as the product backlog. The product owner is responsible for the product backlog. He must assign a business value to each item in the backlog.
      - We prioritize the list and determine the items from the backlog that we can complete during this sprint.
    - The Daily Scrum
      - Every day, the development team meets to talk about where we are in meeting our scrum goal.
      - The scrum is not a detailed review of the progress.
    - The Sprint Review
      - When the sprint has ended, we provide the work to the stakeholders and obtain feedback.
      - The product owner discusses the product backlog with the stakeholders to see if they want to change it.
    - Sprint Retrospective
      - We discuss what went well with the sprint and what didn’t
Software Capability Maturity Model
- This model says that the quality of the software depends on the quality of development. It tells us how capable the organization is of producing quality software based on its practices. An organization starts at the Initial phase, and progresses to the Optimizing phase.
- The phases
  - Initial – the organization has no maturity, and its processes are undocumented.
  - Repeatable – the organization has some repeatable processes, but does not follow them well
  - Defined – the organization has some standard processes that are documented. The processes are not used well.
  - Managed – the organization has good processes that are followed in many circumstances, and the organization is competent
  - Optimizing – the organization has good processes that are followed in many circumstances, and the organization continually improves the processes
IDEAL Model
- This model helps an organization improve their processes.
- The phases
  - Initiating – we realize that we need to improve our process
  - Diagnosing – we determine where we are and where we need to be
  - Establishing – we figure out a way to improve; we put together a plan
  - Acting – we act on our plan
  - Learning – we learn from our experience and improve
Gantt Charts
- A Gantt Chart is a bar chart that shows us a schedule for the development lifecycle
- The chart contains the following
  - A breakdown of each phase including the start date and end date
  - A breakdown of each major milestone
  - A showing of dependencies. A dependency is a phase that relies on the completion of a previous phase.
- We can look at a Gantt Chart to see our progress and identify bottlenecks.
Program Evaluation Review Technique (PERT)
- A tool to determine whether our project is on track
- It allows us to identify the critical path in our project. The critical path is a series of events where any disruption to any event would delay the entire project.

Change Management

Once we release the software, people will want changes. We should have a change management plan in place to make the changes.

Request Control – a user asks for a modification to the software. In this control, we can weigh the cost of making the change against the benefit.
Change Control – we recreate the situation that the user encountered to determine the best change to fix it. We can come up with multiple solutions and test them to determine how they will work in the real world.
Release Control – once we have created a change in the code, we can release it into the real world. We should work with the end users to make sure they are satisfied with the changes. The change must be documented, and the software version must be updated. We call this Configuration Management. It has several phases
- Configuration Identification – we document the configuration of software in use
- Configuration Control – we make changes only according to the policies established by the organization
- Configuration Status Accounting – there is a procedure that tracks any changes made
- Configuration Audit – we perform an audit to make sure that the changes made are the same as the changes that were authorized

DevOps

How do we make sure that all our staff are working efficiently and as a team? DevOps means Development and Operations. IT Operations, Software Development, and Quality Assurance have to work together. DevOps is related to Agile Development in that we are working to release software frequently, and we are working with the business to release software that makes sense to them.

DevSecOps

DevSecOps means Development, Security, and Operations. We are taking DevOps a step further to add security. We are saying that Security is a shared responsibility between the development team and the operations team. If we have built in security during the development lifecycle then we reduce the risk of a security flaw in the final software.

Some parts of DevSecOps

Perform vulnerability scans on the code – look for trouble before we release the software
Verify that the cloud service provider has good security
Set standards and policies

Integrated Product Team The Integrated Product Team (IPT) is a set of people who is responsible for delivering the software or other product. When we assemble the team, we are looking for people with different skills, experiences, and ideas.