Using SSDLC to Prepare for Security Incidents
Join the DZone community and get the full member experience.Join For Free
From a software engineer's point of view, fixing a security issue can be equal to removing an opportunity to exploit a product. While from a security engineer’s point of view, such a fix is just putting a band-aid on a larger problem. Where is the balance?
If we look at software development from a security perspective, the security industry has distilled the development lifecycle into a clear process, which also fits both waterfall and agile development strategies (the most popular SSDLC methodologies are OWASP SSDLC, OWASP CLASP and Microsoft SDL).
Secure software development lifecycle (SSDLC) consists of several stages that go hand in hand with the development stages. A secure SDLC is set up by adding security-related activities to an existing development process.
One of SSDLC steps is incident response.
It doesn’t matter if you use SSDLC in your company or not, your company does or will react to incidents in some way.
Here you can find the 4 typical incident response scenarios, sorted by their cost efficiency levels.
Scenario 1. Addressing Security Issues After Security Incidents
The response typically takes place when a security deficiency is detected. For some companies, this only happens after a breach, when the company internally (or publically, learning about it from the news or twitter) realises that they were hacked and some of the assets were leaked.
In this case, the cost of mitigation is staggering:
- Legal and reputational damage after a successful breach;
- Understanding the causes (unfortunately, the search for the real root causes often gets postponed into the indefinite future and the problems are only addressed with basic patches);
- Chaotic attempts at hotpatching and hotfixing the security issues where possible, not where it’s necessary.
- Putting the additional pressure on security team;
- Aligning policies and processes with the patched-up infrastructure;
- Realigning policies and processes to prevent similar breaches in the future (if some conclusions regarding the root cause have been made).
This is the most stressful and expensive way — you have to mitigate the damage, respond to the security incident, and at the same time, you still need to (urgently) fix your system. For a taste of what can be waiting for you, you can check out the security incident post-mortems by StackOverflow, NPM (who decided to call themselves “Newly Paranoid Maintainers” after the incident), Sentry, or the massive infamous Equifax breach.
Scenario 2. Addressing Security Issues After Assessment/Pentests
In fact, from the perspective of SSDLC, fixing security issues after incidents is no different from fixing issues after a security review (let’s forget about the incident response / forensic / damage assessment parts for a second): the issues are there, already detected, now you have to respond.
More and more companies are acting preemptively — by hiring “white-hat hackers” to emulate realistic attacks on their systems and to find (and get the developers to fix) the security issues before attackers get to them.
By fixing critical problems, companies try to decrease the financial damage in case of an actual attack.
Typically, pentesters target and help to uncover only the most obvious problems so each next pentest might find something else that needs addressing and fixing if the system is sufficiently large.
Pentests are effective if you run them constantly — before each release or every 3-6 months — when you follow some Grand Plan instead of “let’s try to hack this thing again” approach. The Plan usually involves a security roadmap with risks & threats’ model and allows pentesters to focus on the most impactful threats (we’d already covered the topic of dealing with an external security team in Cossack Labs’ blog).
Scenario 3. Addressing Security Issues During the Engineering Process
The next level of security maturity is deploying SSDLC during the actual development — employing security engineers alongside feature engineers, spotting the security problems that may happen early on, and fixing them during development.
The fixes are more consistent and efficient; it’s typically cheaper to find security weaknesses at this stage as it requires less effort from the security team than the need to look for bugs later on.
There are a number of applicable security standards for any ecosystem that can be used by developers and security engineers alike to ensure product security during development. The security industry has accumulated a sufficient body of evidence and knowledge to come up with testing methodologies and common causes of security issues.
However, many security issues would be avoidable, if the bug hunt from the POV of application security had started a few steps earlier.
Also, understanding what data to encrypt can help you comply with the privacy regulations more easily and actually start building with security in mind.
Scenario 4. Preventing Security Issues During Software Architecture Phase
The crown jewel of secure engineering is addressing the security concerns where they need to be addressed — during the design and planning stage of your system.
By spending time on considering the security risks and implications of technical decisions during the initial stage of the project and integrating processes and tools necessary for providing basic security functions, you can eliminate many security issues and threats from the start.
This reduces the chance of somebody potentially exploiting the security-related weaknesses as they’ve been eliminated from the project as early as at the planning stage.
This approach automatically utilizes SSDLC steps during the development process (because security requirements are now part of architecture that needs to be implemented and verified), but the amount of time security engineers spend finding the vulnerable code is greatly reduced. It also implies using regular pentests and security assessments to verify the security posture — but well-designed systems, even when vulnerable, still prevent most attackers from achieving their goals.
In any architecture, security is one of the non-functional attributes, meaning, it does not instantly stand out as top priority. But if the business risks related to possible security incidents are considerable, then scenario 4 is a perfect entrance point into the world of proper security practices.
Why Don’t We All Start With Scenario 4?
Each business is unique, with its individual constraints and requirements and it faces different problems at every stage. You’ve probably already heard all those “get to market”, “deliver fast”, and other popular excuses for not implementing proper security from the very beginning.
In fact, we’ve done a short Twitter survey asking fellow engineers to recall the excuses they’ve been given for dealing with security later (as in: “never”).
Our top picks are:
- “we need to release the app first”;
- "we don't have sensitive data";
- “we are not a bank!”;
- "it will never happen to us. You are being paranoid.";
- "nobody will attack our website";
- “doesn’t bring in any user value”;
- “we can't afford the development costs”.
Software development does not take place in a vacuum. In an ideal a rational world, any piece of code is written to solve some existing real-world problems. So getting to any level beyond scenario 1 requires additional efforts of educating decision-makers about the actual necessity and value of the security efforts.
Scenario 1 will happen to you anyway, sooner or later, whether you want it or not, if you do nothing about the existing security issues.
Scenario 2 requires a bare minimum — compliance pressure looming over your business or a sudden realisation that something could happen. If your company currently has no security stakeholders, but you start thinking about security, asking “white hat hackers” to crack your application(s) might be a good way to start.
Scenario 3 requires a certain maturity of development processes for it to be cost-efficient/productive — security engineers are efficient (bring noticeable value) when you manage your test suite well, document the code, etc. You can make your life much easier by using various tools — code scanners (SAST, DAST), dependency vulnerability management (Snyk, whitesourcesoftware) along with security engineering assistance.
But the situation changes radically if one data breach wipes you out as a business. Suddenly, affording the right approach towards security becomes an enabler and asset rather than an impediment. At this level, you might find the OWASP Software Assurance Maturity Model (OWASP SAMM) useful. It is a framework that helps organizations formulate and implement strategies for effective software security, depending on the specific risks that the business or organization is facing.
Scenario 4 requires the readiness to support strong and mature processes combined with the presence of a strong security stakeholder who is authorised to make decisions.
Implementing scenario 4 is cheaper in the long-term, but requires long-term thinking, which is not quite fit for most startups and is only partially suitable for regular SME.
Choosing the right approach requires a long honest look in the mirror, backed with careful planning and budgeting. But since even startups manage to pull off doing the security right (occasionally), most of the larger companies can do it, too.
Implementing a suitable security and proper SSDLC is an ongoing process with inevitable pitfalls, but the choice is ultimately yours — to go full-on Equifax, with millions of dollars in fines or full-on Google, where the reaction to a suspected security breach resulted in the emergence of new technologies and frameworks.
Kudos to the Cossack Labs' engineering team, who are working on data security every day and made this post possible.
Published at DZone with permission of Anastasiia Voitova, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.