SSDLC and risk assessment in software development
Security is very important during software development, exceptionally when working with digital health, IoT and digital transformation projects, where you have to face a ton of sensitive user data.
Prevention is better than cure, so after over a decade in software engineering and business, I discovered what is the key to a secure software development
- What is SSDLC and what does it consist of?
- What is a reasonable approach?
- Why important are threat modeling and risk assessment?
- What are high-risk domains and how to handle them?
- Who should be responsible for security in your company?
What is Secure Software Development Life Cycle (SSDLC)?
SSDLC, in a nutshell, means that we won’t wait with security-related activities till the end of the development. The idea is to have them integrated into our process all the way.
With that in place, it’s way easier to create secure software as security is a continuous concern, detect early flaws in the system, reduce costs as a result of early detection and resolution of issues and an overall reduction of intrinsic business risks for the organization by raising awareness of security considerations by stakeholders.
There are definitely some actions that can be taken by developers or testers in their day-to-day activities to improve the security posture of your organization. Like introducing static and dynamic code analysis tools, penetration testing, defining security requirements or performing threat modeling.
Although I want to emphasize this very strongly here that it’s our responsibility as CTOs or managers to educate ourselves and co-workers on the best secure coding practices and available frameworks for security.
Becoming paranoid with security, on the other hand, is also not a good idea, as with all extremes. I mean it would be great for all products but unless we are not a bank or any ultra-specific data processing company it's recommended to stay reasonable with our actions.
As I mentioned earlier it’s practically impossible to identify every potential system flow. We should put enough effort to try to identify the most crucial ones especially, without spending horrendous amounts of time. There are a couple of techniques that can be used that will help us get the knowledge about or system holistically and also identify the areas where risk might be the highest. And then we can focus more only on those specific areas. We should end up with a list of all risks (all important ones) that are connected to our product. Next step is to assign to each of them the cost of failure that it can generate — the expected loss, and also what is the level of predicted probability of it happening in production.
With that done it’s very easy to prioritize all of them. Only those with high effect should be considered as ones to apply countermeasures. Of course, it all depends on the available resources. So a classic risk assessment job. If you are not familiar with how it works you can discuss it in more details with me.
The cool part is that it gives a holistic view of the system as a whole, raising awareness among developers about potential problems and even show possible wrong use cases we could have forgotten about.
What are the high-risk domains?
Risk assessment is a good exercise for every project but if your solution uses one of the following areas of technology I would say it's a must-have in a development process!
Data storage
The one of the top and obvious ones are of course data storage of any kind. It might be local or in the cloud. Almost every app or piece of software is meant to hold and process some sort of data that needs to be stored somewhere. In most cases, we deal with users very private and confidential information. It’s our responsibility to make sure that those data will be a top secret, and we won’t share or give access to them to any third party without our and our users’ knowledge.
The concept and practice of securing storage are gaining momentum, but it still hasn’t taken off really. I really don’t understand that especially if you look at the business risk that it brings. Storage vulnerabilities are a fact. What is worse is that many of them are very easily exploited, meaning someone gets access to all collected data.
The real business risks are associated with compromising databases, not data that we are sending there. But it doesn’t mean we should forget about protecting sensitive information as it crosses the wire or the airwaves. Although communication itself isn’t the worst part usually as SSL and OAuth are pretty standard now, definitely for particular kind of products is super crucial.
Scale problem
The real challenge is to make sure we prevent all users' data vs. just single user data, which usually comes down to designing and developing secure backend API — as that’s the place where all collected and hopefully encrypted data is gathered and accessible.
API is the key
A secure API is one that can make sure of the privacy of the data that it deals with by making it visible only to the Users, Apps, and Servers that are authorized to consume it. Likewise, it has to be able to take care of the integrity of the data it receives from other servers and clients with which it talks directly to.
Those two aspects are essential for a reliable API.
Mobile apps
If our business has a mobile application might be worth mentioning that environments our apps may be running on may vary from those officially released systems. Jailbreaks and rooted devices are still a thing in today’s world, and we have to remember that permissions on those systems are completely different from official secure releases.
3rd party software
Every running software including the ones from our products is constructed from code by developers. They might be using external 3rd party libraries and frameworks to optimize their work or support external services. It’s also important to check if those 3rd party additions are secure, and updated on a regular basis.
Product intellectual property
There might be cases like with games for example that we want to be sure that no one is going to try to modify them in their favor or to distribute omitting us, or again steal our technology/work to create competitor product.
Cryptography/Encryption
Cryptography & Encryption Key Management is closely connected to software security. It’s just important to mention that there should be a policy to be sure to update them once in a while. Technology might change and we should be ready for that.
Human factor
And most of the time the weakest link in the chain is a human. It’s OK we all make mistakes, it makes us humans. We just need to be aware of that and counteract. Things like storing and sharing important keys and credentials are the things we don’t think about. The most secure system won’t win if someone is just gonna simply take over admin credentials from someone. Creating office policy in terms of communication and data importance is as essential as secure data encryption.
Summary
So as you can see, almost everybody should care about security when building software. The last and good motivation for everyone might be different regulations of data storing that might result in millions of dollars of fines.
Security is an endless fight. If we are going to forget about one thing that is going to be exploited, should be a way easier to fix and won’t look as bad as just having everything on a plate waiting to be taken. Especially when explaining ourselves before investors or company board. Also, a security audit is part of a process of due diligence.
A business should have one person responsible for security matters. Without a dedicated person that responsibility will usually be handled by a CTO or head of technology.
Check my previous articles connected to this topic:
If you share my ideas or have a question about security, please leave a comment.
If you have a project to discuss, find out what I can do for you as a CTO.
Here you can find my articles regarding code quality and building software development teams:
