Introduction
I recently finished reading the book Designing Secure Software, it was extremely good. A book I recommend all software engineers to read.
It wasn't really a coincidence that I started looking more into security in software engineering. At Bobsled, the tech start-up I work for, we're building a cross-cloud data-sharing platform. Since we're dealing with data, you can probably tell security is extremely important, not just for us, but for our customers and even their customers.
I find it fascinating that security isn't spoken about too often in software engineering, when it should be the default way we develop software, with security in mind.
Security is extremely important. Another thing worth sharing: Companies Lose $400 Billion to Hackers Each Year.
In this article, I want to share some ways you and your team can integrate security into your software development process. Some ways are more effort than others, but as they say, starting with something is better than nothing.
I do want to mention that I'm not an expert in this. I'm learning and recently finished reading the book I previously mentioned. The things I mention below aren't silver bullets or anything. Whatever you decide to try or do next, dig deeper into it and make sure you're deciding on something that's worth the effort.
Security Design Reviews (SDR)
The book mentions SDRs. The author mentions that they take a little of the design time and never feel like a waste. I have never done them or seen them in practice, but to me, it sounds like something good we can do regularly when developing our software.
The author says they should be done once the design is complete. I like how he emphasizes that it is also the designer's responsibility.
To be clear, designers should never ignore security and rely on the SDR to fix those issues for them.
SDRs should be documented effectively and kept up-to-date.
I won't go in-depth into each step, but here are the six steps:
Study the design and supporting documents to gain a basic understanding of the project.
Inquire about the design and ask clarifying questions about basic threats.
Identify the most security-critical parts of the design for closer attention.
Collaborate with the designer(s) to identify risks and discuss mitigations.
Write a summary report of findings and recommendations.
Follow up with subsequent design changes to confirm resolution before signing off.
Code Reviews
During code reviews is also another time to look for potential security issues. For instance, if something has been validated on the client, but not the server, then that should probably get fixed.
I have read many code reviews guideline but found very few that mention looking out for vulnerabilities.
Code reviews, we do them often as software engineering, looking for security issues during those times shouldn't be a problem. The effort is quite low as well.
STRIDE
You could ask yourself what could potentially go wrong. Now, there are a lot of answers to that, all the different threats, entry points, vulnerabilities, etc. that could happen to the system.
STRIDE is a framework that focuses on the process of identifying threats by giving you a checklist of specific kinds of threats to consider.
What can be spoofed (S), tampered (T) with, or repudiated (R)? What information (I) can be disclosed? How could a denial of service (D) or elevation of privilege (E) happen?
What's interesting is that you could go in-depth about each category, and the examples would be different depending on the type of system you're developing.
I won't go in-depth about the categories, but I do want to mention that this is something we've done at Bobsled where we looked at the different things that could go wrong in our system using the STRIDE framework. We did this on Miro where we put the different failures into the category they belonged. I highly recommend doing this with your team.
As for how often this should be done, I honestly don't know.
Patterns
This is taken from the book. It has a chapter on security patterns. I really dig the part about Exposure Minimization.
Monitoring
You can monitor your system too. Seeing if any security issues get spotted.
Now, I will say this might not work for your system, it depends on what you're working on and building, but it is something I learned from Viljami.
Products for this exist, such as Datadog for an instance. It's worth taking a look.
Penetration testing
You can hire a cyber-security expert to do penetration testing. This means they would try to find and exploit vulnerabilities in your system. The purpose of this simulated attack is to identify any weak areas in the system that an attacker could break through.
With the result, you could find areas where your system needs to improve.
Conclusion
Security is extremely important. It is something we should keep in mind when developing software, it should be the default way we build software, with security out-of-the-box.
