Risk Mitigation in Software EngineeringPublished February 7, 2019 by Karen Walsh • 4 min read
Developing software while maintaining its embedded security can feel like the “Impossible Dream.” As you update your product, you’re potentially adding new vulnerabilities. As part of the risk management process in software engineering, you need to work with cybersecurity professionals throughout the software development life cycle (SDLC) to create a mature security profile.
Risk Mitigation in Software Development & Engineering
What are the guiding principles of SDLC risk mitigation?
Risk mitigation in software development parallels the process used by traditional businesses. As outlined by the Open Web Application Security Project (OWASP), the Software Assurance Maturity Model (SAMM) focuses on assessing, formulating, and implements a software security strategy that integrates into the SDLC. Thus, regardless of development methodology, you can follow a risk management process that allows you to secure software throughout the development process.
How Does SAMM approach risk mitigation?
OWASP embeds risk mitigation and response throughout the development cycle. Functionally, each group within the organization retains reponsibility at different points in times.
OWASP breaks down software development into four basic business functions, each of whom then engages in different risk management activities.
Thus, the responsibilities are integrated not only into the SDLC but also the organizational tiers.
What are Governance function’s responsibilities?
Governance, as defined by OWASP, focuses on business outcomes and deliverables such as strategy, metrics, policy, compliance, education, and guidance.
The Strategy & Metrics (SM) Practice
The SM Practice creates measurable security goals to mitigate the business risks inherent in data events.
The Policy and Compliance (PC) Practice
The PC Practice establishes written standards that meet legal and regulatory requirements, including audits that provide the necessary assurance.
The Education & Guidance (EG) Practice
The EG Practice increases workforce access to information so that they can identify and mitigate security risks more effectively.
What are Construction function’s responsibilities?
Construction focuses on defining goals and creating software within projects. As such, you need to include the project management team as part of these steps.
The Threat Assessment (TA) Practice
As part of the TA Practice, you focus on risk identification and risk analysis. Not only will you look at impact an attack have, but you also look at the probability of occurrence.
The Security Requirements (SR) Practice
Initially, The SR Practice analyzes high-level security requirements based on how an organization intends to use the software. From here, it reviews new risks and how to mitigate them as the software matures. Thus, you need to consider interactions with suppliers and adhere to audit standards as required in Service Level Agreements (SLAs).
The Security Architecture (SA) Practice
Rather than waiting to secure your software upon completion, the SA Practice builds in security by default. Thus, you want project teams to focus on explicitly designing software with security functionality in mind.
What are the Verification function’s responsibilities?
Verification relates to continuously testing, reviewing, and evaluating software for new risks.
The Design Review (DR) Practice
The DR Practice assesses design and architecture to detect and address issues early in the process. The goal of DR is to locate security issues before they become costly.
The Implementation Review (IR) Practice
During the IR Practice, you review source code and configurations for security vulnerabilities. While in the early stages of development, an organization can use simple checklists, often mature software development companies used automation to provide greater coverage.
The Security Testing (ST) Practice
The ST Practice focuses on reviewing security in the runtime environment, functionally looking at it as it will work after deployment. As such, this can include traditional penetration testing for high-level test cases or review for other misconfigurations.
What are the Operations’ function’s responsibilities?
Operations relate to all activities that are part of the software’s release, such as shipping, deployment, hosting, and operation in the runtime environment.
The Issue Mangement (IM) Practice
The IM Practice creates processes for handling issues reports and operational incidents by assigning roles, organization a formal incident response process, and tracking issues. Additionally, it requires communication between all stakeholders.
The Environment Hardening (EH) Practice
To protect the application, the HR Practice focuses on ensuring that the underlying infrastructure maintains the software’s security posture rather than undermining it. To ensure manageable deployment of security patches, you need to keep the development team information and find ways to review the operating environment.
The Operations Enablement (OE) Practice
The OE practice focuses on risk monitoring to ensure that your project teams communicate risks to users and operators. As part of OE, you need to create documentation with details that users and operators need and share those with each release.
Why embedding security within software development matters
As more companies seek to use Software-as-a-Service platforms to enable their businesses, they also recognize that vendors are one of the most significant data breach risks. Moreover, with the glut of SaaS platforms on the market, you can stand above the competition if you’re focusing on security as a primary differentiator.
However, most SaaS platforms recognize this. Many may say they’re secure, but vendor data environments remain murky. Thus, you need a project manager who focuses on project risk management and mitigation to ensure that you’re genuinely securing your product.
How ZenGRC Enables Risk Management During SDLC
The OWASP SAMM requires documentation from a myriad of stakeholders throughout the development cycle. Early on, you may be able to manage this documentation on a shared drive, if you want scalability, you need an automated process for tracking and documenting your security reviews.
ZenGRC allows you to prioritize tasks so that everyone knows what to do and when to do it so that you can more rapidly review the “to do” lists and “completed tasks” lists.
With our workflow tagging, you can assign tasks to the individuals in your organization responsible for the activities involved in risk assessment, risk analysis, and risk mitigation.
Finally, with our audit trail capabilities, you can document remediation activities to prove that you maintained data confidentiality, integrity, and availability as required by law.
For more information about how ZenGRC can streamline your GRC process, contact us for a demo today.