A security vulnerability is an error that an attacker can exploit system from security perspective. The same security vulnerability can be found with product/solution in windows, mac and Linux environment. Fix for a security flaw depends on the coding language and underlying operating system or browser.
Security vulnerabilities are classified in to security taxonomies or flaw categories by computer security researchers. These classification are done independent of programming language, operating system or browser. Here are few links/ points to understand better.
- CVE is a dictionary of publicly known information security vulnerabilities and exposures
- CWE provides a unified, measurable set of software weaknesses enabling more effective discussion, description.
When security researcher report security flaw, the researcher also supplies CWE-ID to represent flaw. To know more about CWE-ID, please check FAQ compiled from MITRE.
For the reported security flaw, the security vulnerability of flaw can be classified to two categories.
- Flaws in product/solution implementation
- Flaws in product design.
The vulnerabilities present at design level are hard to detect and handle. Design level vulnerability are the most prevalent and critical ones. To determine that a program has design-level vulnerability is difficult, even with great expertise. The harder it is to automate the same.
Some software development approaches identify issues by performing a security assessment of applications after they are developed and then fix these issues. Patching software in this way can help, but it is a costlier approach to address the issues. This cycle of Testing – Patching – Re-testing runs into multiple iterations and can be avoided to a great extent by addressing issues earlier in the Life Cycle.
Once can choose to look product from security angle only after a hacker reports security vulnerability from the field or can choose to be prepared and incorporate security practices as part of software development cycle. Here are articles to facilitate implementing S-SLDC in your firm.
Requirements & Planning Stage: Right from the start time where product features are specified, the security requirements of the product/solution needs to be identified and written down. In addition, it is worth to create a list of security abuse to be handled by the product and this in more apt time to undergo security training, if needed.
- Make the test engineers aware of security requirements and encourage them to write risk based security tests in their test plans.
- Identify features and plan features to be implemented as part of agile milestones and track them for completion from security standpoint.
At design Stage, identify Design Requirements from security perspective, perform Architecture & Design Reviews and Threat Modeling with respect to security. In addition, the design should be subjected to a risk analysis for security. Any security flaw identified during design stage is easier to fix flaw with less effort compared to flaws found across future phases.
Coding Stage Coding Best Practices for Security enables developers to write code, less prone to security vulnerability. In addition we need process is required to evaluate code on regular basis for security flaws and identify security flaws. The process of evaluation can happen at regular intervals, end of agile milestone or end of every sprint.
Security vendors like Veracode offer static analysis as service to find security flaws in the code, if the code binaries are uploaded. Every organization needs a different discussion to understand risks involved in sharing code with third party, how far to trust them, what protection are provided by security vendors.
Once code is assessed for security vulnerability, the first thing to perform is understanding each one of the security vulnerability listed in report. For every vulnerability, first understand why it is classified as security flaw, what is severity of the flaw and analyse the same. Your earlier risk analysis during design stage can help you to perform better analysis of vulnerability to come with mitigation plans (where needed).
Most vendors are not aware whether usage of tool happens inside or external to your network or enterprise network. This leads to the challenge of more security flaws reported in product/solution. Plan for resources to interpret security flaw in context of your application and that specific context drives decision to fix flaw or mitigate flaw.
For security flaw reported either through self-analysis or third party ,
- If you are aware of the solution, the flaw needs to be fixed. Go ahead to fix vulnerability.
- Flaws may be reported in internal utility of the product used within network. You may choose to mitigate the flaw and not fix the same.
- Some flaws may not have immediate fix. You need to follow-up with your teams and community to find solution.
- Your product/solution has made use of new approach to security or as part of implementation. As your implementation is not yet a standard, security vendor reports the same as flaws. You may choose to mitigate the flaw as “False Positive” and provide reason why the flaw does not impact your solution.
Depending on your team’s bandwidth, team can start working on security flaws starting from severity “High” down to ones with severity “Low” or “Informational”. Any security flaw identified during coding stage is easier to fix flaw with less effort compared to flaws found after production.
Your web product has moved to pre-production or staging phase. This is time where penetration testing is planned to happen. Today vendors like Veracode offers dynamic analysis/security black box testing to identify flaws in product deployed in staging environment, simulation of vulnerability in real world.
Once system goes in to production, security lapses also come as feedback from field and it becomes important to capture security flaws reported from field and track security incidents reported from the field to closure. Managing security incident involves tasks like managing patch releases, upgrading current threat model, reassessing the code thru static analysis.