This week it won’t be a technical hacking exercise, but instead researching a topic that is fairly important in real life: What role do various security tools have in a real-life software project?
Software projects have multiple different activities and do not only concentrate on development and testing. There are customer and regulatory requirements that affect the functional (“features”) and non-functional (“quality”) requirements, and may have security impact. Deployment and operational phases are also a part of software development. In modern software engineering, “DevOps” teams that are responsible for both development and operations further blur the area between software security and “IT security”.
This assignment looks at what niche a software security tool would fill in a project, and which aspects are not helped by tools. It is easy for a company to spend a lot of money on a tool that is under-utilised, or does not help in the big picture; on the other hand, not using automation may make some software security activities nearly impossible.
Before you start writing
The reading list in this week’s course notes has several useful pointers, and I really encourage you to first look at the following before you start writing:
- Have a look at the BSIMM software security activity list. This is a list of software security activities that many companies have been observed as performing. Under each activity, there are a number of examples of how companies have actually done this.
- Have a look at Microsoft’s SDL process guidance. You can click on the various phases of the SDL to see what sort of activities Microsoft would mandate in their development.
By the way, not everything in these sources is necessarily a good idea to do in your specific situation. Don’t interpret these as being the “truth” for all software projects. These are views and examples, some of the activities having more experience backing them up than others.
When reading the sources above, try to see the big picture by thinking about the following questions while you read.
- Is there a specific type of software security activity that seems to be usually facilitated by use of tools or automation? Why do you think this happens?
- Are there types of software security activities that do not seem to be using any sort of tools or automation? Is there anything in common with these activities?
- Would you expect some types of software projects to need less or more tools, or different kinds of tools? Examples of different projects would be:
- An agile (e.g., Scrum) project that develops a lot of entirely new code for Node.js;
- A maintenance project with a gigantic C++ codebase mainly written in 1992;
- A safety-critical project in C for medical devices;
- An open-source project in Python creating GNU GPL code published on Github,
- A classified non-U.S. military project using Erlang.
Choose one commercial or non-commercial tool that is primarily marketed for increasing software security. There is a short list of tools below; you may select one of these, or something else.
However, when you select a tool, it must be one that has a direct impact on software development or operational deployment. Do not select a product such as a firewall, a VPN, an IDS or antivirus software.
Example tools (and companies that provide tools) are provided below. Many of the companies make several tools and bundle them under various names. You can select the one you want. I have indicated the general class of (at least one of) the tools.
Note that the University, or the lecturer, do not imply that any of the tools would be somehow good, bad, useful, or not useful. Listing a tool here also is not an endorsement. All trademarks are property of their respective owners.
- Vulnerability scanners
- Security testing frameworks
- Static analysis
- Source code compliance scanners
- Fuzzers and robustness testers
- Threat modeling tools
- Configuration checkers
Once you have selected a tool, read some of its marketing material. Things like feature lists, white papers, user guides, and demo videos would be useful resources. Make note of the arguments that it is being sold on, what it exactly does (“scanning” is a bit too high level description) and what is the tool expected to deliver.
What to return
Answer the following questions about where the tool would fit in increasing security in a software project. Please copy each bullet point into your submission and answer directly under that bullet point.
Only a few sentences per bullet point, below, are necessary. However, ensure your own analysis shows through.
- Which tool did you research?
- Which general software development activity would the tool be used in? (E.g., project governance, training, product management, design, implementation, testing, deployment, operations.)
- What does the tool, technically speaking, do?
- In that specific area of software development, what does the tool not help with that would still need to be done?
- What types of risks does the tool mitigate?
- What sort of difficulties would you foresee when introducing the tool into a real-world software project - and crucially, why you think you might run into these issues? (Examples of problems could be: Does it need specialists to run; does it scale into a large organisation; would it need a lot of work to get into use; would it be accepted by developers under time pressure; would it slow down development / integration / testing; would it require manual work or integrate in the toolchain or automation; would it fit agile development; and so on.).
Note: The submission must not cut-and-paste text from any vendor material. Do not write a marketing pitch for the product. There is also no need for ”introduction” or ”conclusion” sections.
There’s an absolute maximum length of the submission and it is 500 words (not counting the questions).
There is no minimum length; it is when you think you’ve answered the questions sufficiently to convey your own analysis.
The first questions need to be answered to pass the assignment. The actual points will be determined by the last three questions.
Your score will depend on how well your analysis targets the last question. You should aim to answer the ‘why’ part of why you think a certain tool has problems. Just saying what difficulties you foresee, without explaining why, will not achieve a high score.