-
Securing Software Development Methodologies
There are several software development methodologies. You will know about these from the software engineering modules.
The Waterfall Model
The waterfall model is a sequential design process, used in the software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Design, Construction, Testing, Production/Implementation, and Maintenance
Agile
Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organising, cross-functional teams. It promises adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change. It is a conceptual framework that focuses on delivering working software with the minimum amount of work. Agile is underpinned by a few principles which are discussed below.
Principle number one: At the core of Agile, one puts the customer first. One needs to be clear on who the customer is, what problem one is trying to solve, what matters to the customer, and prioritize. Always come back to who the customer is. In some cases, the customer can be an internal customer. In typical organizations, the distance between the customer and the people doing the coding is several layers of translation. That can only lead to wrong prioritization, compromise, and, in the end, one’s likelihood of delighting the customer and doing something that is reduced. That’s principle number one and incredibly important.
The second principle is around how to focus on people interactions versus process. So, how do you make sure that one’s team members don’t just take a project plan on what needs to be done and toss it over the wall to [another] team, but actually collaborate? How do you all come together to align on the objectives and mission that you have for your customers, and work to figure out the best solution to bring that to life? It’s about bringing the customer to the table. It’s part of the interaction of processes that takes away so much of the focus on just checking a box—to more of a focus on how to serve the customers and get to the right solutions for them.
The third principle that is very important is welcoming change—so removing the barriers that if you change, [the idea that] if there’s failure, that something was wrong. Rather to turn it around and say, we’ve learnt something. We’re going to integrate that learning into the next iteration. Because at the heart, and the way most organizations will implement these principles, is quick cycle times: two-, four-, six-week sprints, which is often the name that is used; and to deliver something at the end of the sprint, you have the ability to learn. If you do a quick sprint, you focus on delivering something. You bring the customer to give you feedback on what you’ve delivered. You have an inspired team.
Now we’ve taken the three principles and we’ve gotten them to work together. That’s one way to implement the principles, although it’s not the only way. But you can begin to see how it’s self-reinforcing.
The fourth principle is to empower the team. The team knows more about the customers, it knows more about what it can do. If you make it autonomous, within some boundaries, you can have something special. The team performs at a new level. The quality of the product goes up. It’s scary for most organizations to let go. We have built organizations that are hierarchical, inspired from the military. Everything needs to flow up, all the way to the top, to people that have been promoted—based on past behavior and successes—to people that supposedly know more.
Every time you go up and down this chain, you have translation layers, and you lose some of the nuances. Let’s flip it around. We’re going to let the people who are closest to the problem, closest to the customer, make the trade-off within the scope that we’ve agreed is the scope that they can operate in. That’s what makes it agile. That’s what makes it speedy. That’s what makes it flexible. Unless the whole business is operating in an agile manner, you’ve always got this layer of interaction between agile teams.
There have been attempts to map the secure development lifecycle to agile.
The Microsoft Secure Development Life Cycle
Security Development Lifecycle (SDL) is a software development process that helps developers build more secure software and address security compliance requirements while reducing development cost.
Microsoft Security Development Lifecycle
-
Microsoft SDLC
Microsoft proclaimed this as a result of a commitment to trustworthy computing. Microsoft defined the SDL to address security issues they frequently face in their products.
- SDL comprises a set of activities that complement Microsoft’s development process. The activities are particularly aimed at addressing security issues. SDL can be characterised as follows:
- Security as a supporting quality
- Well-defined process
- Good guidance
- Management perspective
OWASP CLASP
CLASP – Comprehensive, Lightweight Application Security Process
This provides a well-organised and structured approach for moving security concerns into the early stages of the software development lifecycle whenever possible
Originally defined by Secure Software and later donated to OWASP, CLASP is a lightweight process for building secure software
It includes a set of 24 top-level activities. The activities can be tailored to the development process in use.
- Key characteristics include:
- Security at the centre stage
- Limited structure
- Role-based
- Rich in resources
-
TouchPoints
The touchpoints are one of the three pillars of software security. Attaining software security may not be easy but it doesn’t have to be a burden.
By describing a manageably small set of touch points (or best practices) based around the software artifacts you already produce, religious warfare over process is avoided and the focus is set to the business of software security,
Touchpoints provides a set of best practices that have been distilled over the years out of the extensive industrial experience of its proposer. Most of the best practices, named activities from here on, are grouped together in seven so-called touch points. The numbers in the diagram can be used as a ranking of the importance of that activity.
7 touchpoints for software security
Gary McGraw's seven best-practice "touchpoints" for secure software development involve knowing and understanding common risks, designing for security, and subjecting all software artifacts to thorough, objective risk analyses and testing.
Source: "Software Security: Building Security in," by Gary McGraw
Each one of the touchpoints are applied on a specific artifact and each touchpoint represents either a destructive or constructive activity.
1. Code Review (Tools). Artifact: code. Constructive activity.
2. Architectural Risk Analysis. Artifact: design and specification. Constructive activity.
3. Penetration Testing. Artifact: system in its environment. Destructive activity
4. Risk-Based Security Testing. Artifact system. Mix between destructive and constructive activities
5. Abuse Cases. Artifact: requirements and use cases. Predominant destructive activity.
6. Security Requirements. Artifact: requirements. Constructive activity.
7. Security Operations. Artifact: fielded system. Constructive activity.Code review with a tool
The code review is essential in finding security problems early in the process. The tools (the static analysis tools) can help the user to make a better job, but the user should also try to understand the output from the tool; it’s very important to not just expect that the tool will find all the security problems with no further analysis.
A few tools (commercial or not) are available, like CQual, xg++, BOON, RATS, Fortify. The most important part is the list of key characteristics that a good analysis tool should have and some of the characteristics to avoid.
- The key characteristics of a static analysis tool:
- be designed for security
- support multi tiers architecture
- be extensible
- be useful for security analysts and developers
- support existing development processes
- The key characteristics of a static analysis tool to avoid:
- too many false positives
- spotty integration with the IDE
- single-minded support for C language
Architectural Risk Analysis
Around 50% of the security problems are the result of design flows, so performing an architecture risk analysis at design level is an important part of a solid software security program. The architectural risk analysis must be integrated in and with the Risk Management Framework with a “forest-level” view of the system.
- Three step process for risk analysis:
- attack resistance analysis – have as goal to define how the system should behave against known attacks.
- ambiguity analysis – have as goal to discover new types of attacks or risks, so it relies heavily on the experience of the persons performing the analysis.
- weakness analysis – have as goal to understand and assess the impact of external software dependencies.
Software Penetration Testing
Penetration tests can be misused and are used as a “feel-good exercise in pretend security”. The main problem is that the penetration tests results cannot guarantee that the system is secured after all the found vulnerabilities had been fixed and the findings are treated as a final list of issues to be fixed.
Penetration tests are best suited to probing (live like) configuration problems and other environmental factors that deeply impact software security. Another idea is to use the architectural risk analysis as a driver for the penetration tests (the risk analysis could point to more weak part(s) of the system, or can give some attack angles). Another idea, is to treat the findings as a representative sample of faults in the system and all the findings should be incorporated back into the development cycle.
Risk-Based Security Testing
Security testing should start as the feature or component/unit level and (as the penetration testing) should use the items from the architectural risk analysis to identify risks. Also the security testing should continue at system level and should be directed at properties of the integrated software system. Basically all the tests types that exist today (unit tests, integration tests) should also have a security component and a security mindset applied.
- The security testing should involve two approaches:
- functional security testing: testing security mechanism to ensure that their functionality is properly implemented (kind of white hat philosophy).
- adversarial security testing: tests that are simulating the attacker’s approach (kind of black hat philosophy).
Penetration tests represents an outside->in type of approach, the security testing represents an inside->out approach focusing on the software products “guts”.
Abuse Case Development
The abuse case development is done in the requirements phase and it is intimately linked to the requirements and use cases. The basic idea is that as we define requirements that suppose to express how the system should behave under a correct usage, we should also define how the system should behave if it’s abused.
A possible process for building abuse cases is presented the diagram.
The abuse cases are creating using two sources, the anti-requirements (things that you don’t want your software to do) and attack models, which are known attacks or attack types that can apply to your system. Once they are done, the abuse cases can be used as entry point for security testing and especially for the architectural risk analysis.
Software Security Meets Security Operations
The main idea is that the security operations peoples and software developers should work together and each category can (and should) learn from the other (category).
The security operation peoples have the security mindset and can use this mindset and their experience in some of the touchpoints presented previously; mainly abuse cased, security testing, architectural risk analysis and penetration testing.