Back

The Importance of Reviewing Source Code for Security Vulnerabilities: Two Years After the SolarWinds Breach

We’ve made it to the two-year anniversary of the SolarWinds cybersecurity breach. Not the anniversary of its public disclosure, but during Fall 2019 attackers first gained access to the SolarWinds systems. There’s a lot to learn from the breach. The biggest takeaway? Supply chain vulnerabilities are not to be taken lightly.

The breach highlights the significance of a thorough and robust review of security vulnerabilities in the source code of software products – namely hidden backdoors. Analyzing the attack, the threat actors were able to inject malicious code and successfully masquerade the payload, which should have been detected during a secure code review or audit activity focused on finding anomalies or a malicious piece of code.

While many software suppliers today do some form of secure code review activity on their software, there are major variations in the depth and breadth of reviews performed across companies that can drastically impact results. In this blog, I’ll dive into the secure code review process and explain the necessary components needed to identify the risk your source code may pose to your organization if it is not reviewed thoroughly.

What is a Secure Code Review? 

For a detailed and digestible breakdown of secure code review, read OWASP’s Code Review Guide. The authors reiterate that “secure code review is the single-most effective technique for identifying security bugs early in the system development lifecycle.” Let’s start with the basics:

As I define it, secure code review is a process used to verify if the source code being developed contains security flaws and that it has the necessary security controls to prevent an adversary – external or internal – from exploiting vulnerabilities in software.

In other words, the purpose of a secure code review is not only to find security vulnerabilities but also to evaluate if the source code is robust enough to evade security attacks. In addition, it can also verify that developers are following your secure development policies and procedures.

While penetration testing can help you look at your application security holistically, supplementing your testing strategy with a secure code review allows for more comprehensive coverage. According to the OWASP Code Review Guide, “a general rule of thumb is that a penetration test should not discover any additional application vulnerabilities relating to the developed code after the application has undergone a proper security code review.” 

When Should I Implement Secure Code Review or Static Analysis? 

Depending on the criticality of the application and AppSec program maturity, security teams may implement secure code review at various touchpoints in the SDLC or bake it into an Agile development process. 

Just as penetration testing adds more value to your security program when it is implemented continuously, secure code review – when done incrementally and across the SDLC – can dramatically improve your secure software development lifecycle. Below, I outline five key timeframes where secure code review or static application security testing (SAST) should be implemented:

  1. During development:
    Integrating security scanning directly into the developer’s integrated development environment (IDE) is a great way to avoid introducing security vulnerabilities in your code as the software is being written. It provides real-time feedback on secure coding guidelines and is also a great tool to help your teams get in the habit of secure development. Finding and fixing vulnerabilities during development ensures they do not get propagated further down the road. According to National Institute of Standards and Technologies (NIST), the cost of fixing a security defect once it’s made it to production can be up to 60 times more expensive than during the development cycle.
  1. Pre-commit checks (pull/merge requests):
    When merging code from multiple developers into a single branch, it is highly likely that security vulnerabilities will be introduced. While peer code reviews on pull requests generally focus on functional bugs, it is recommended to also do a quick check on security issues. This will help eliminate critical and high severity issues early in the chain. Today, all popular code repositories with code collaboration features provide integration with SAST tools. However, automated tools tend to be too noisy and should be carefully configured with limited rulesets at this stage to not significantly impact developer workflow.
  1. Post-commit (during build/testing phase):
    As source code gets ready to be part of final release of a product, a thorough secure code review is critical to ensure the product is free of security bugs. SAST tools with a broader ruleset can be integrated into continuous integration pipelines to report on existing security vulnerabilities, which can be reported into bug trackers or team backlogs.

    However, breaking the build every time a security bug is reported may not be viable, since tools are prone to false positives. One can improve static analyzers by refining rulesets using regular feedback from reported issues.
  1. Post deployment:
    While integrating static analysis tools in the DevSecOps pipeline may seem straight forward, the speed at which new code is expected to release makes it harder to find and fix all security bugs in every sprint or release.

    Running a SAST scan periodically from production code repositories and having scheduled secure code reviews implemented into your annual calendar will help give your security posture a boost. Also, these help meet the requirements of governing bodies and regulations such as PCI DSS and HIPAA.

    To eliminate noise and reduce the workload on developers, these scans should be triaged by your product security experts, or “champions,” who can closely work with the developers to resolve vulnerabilities. However, not all organizations are adequately staffed with security analysts that have secure code review skills making partnering with a secure code review vendor a viable option. 
  1. Suspicion of malicious intent:
    This is a more reactive strategy for secure code review. When you’re suspicious of malicious activity in your organization, or have detected a potential breach, do an on-demand code review scan to validate your suspicions and identify the breach at its core.

    Remember that code review activities should be aligned with your organizations goals and provide value. For example, in case of malicious threat vectors, review should be focused on identifying points of interest (POI) in code that can combine to produce malicious constructs. Analyze the interaction between various POIs, looking for mutation, obfuscation, and inversion of control used to conceal malicious activity.

The Secure Code Review Process

There are many variables that can impact the secure code review process. As mentioned at the beginning of this article, the depth and breadth of a secure code review can vary greatly. To get the most out of your testing, here are four areas that can make the biggest difference:

  1. Define the Scope
    The scope of each secure code review will vary based upon a multitude of factors, including the threat factors involved, the coding languages, number of lines of code, and the criticality of the application. Is it a “crown jewel” application? If so, it will be important to increase the frequency of your code review cycles and put emphasis on the remediation of vulnerabilities.
  1. Custom Checklists
    Predefined, custom checklists based on the threat model of your product are essential for secure code review success. Generic checklists aren’t very helpful, considering application security is not one-size-fits-all. Custom checklists for each software application can be extremely time-consuming. To help, use frameworks such as the OWASP Application Security Verification Standard as a starting point. Lastly, and perhaps most importantly, ensure your checklists are consistently maintained and updated.
  1. Automated Scanning
    Automated vulnerability scanning enables manual testers to spend more time finding business-critical vulnerabilities in the code. All automated scanning tools are not created equally – some are better than others and some meet unique needs. Are your tools meeting your requirements? Are you being strategic with your automated scanning? Audit and recognize whether there are existing gaps in your tooling and have a plan to evolve and enhance your technologies. Look for these three qualities in your automated scanning tools: the ability to be customized, integrate into the CI/CD pipeline, and reduce noise/false positives.
  1. Manual Testing
    To find vulnerabilities that tools miss, human context is necessary. Manual secure code review is especially important for high-risk, sensitive applications – the one with greater business risk. Humans can apply the needed business logic to write custom scripts and approach a secure code review from the perspective of a real adversary. Additionally, with automation, comes false positives. Having a human triage, the vulnerabilities found in your code is a huge benefit – consuming a raw, data-heavy report is not enough. 

How to Choose Your Secure Code Review Team

To outsource or not to outsource. There are benefits to building a secure code review team within your organization, but it does require a lot of investment and time to evolve your tools and train new resources. Do you have the capacity to maintain the automated scanners, increase the frequency of your secure code review, and update your checklists? If not, here are four reasons to consider working with a secure code review provider:

  1. Better coverage (more vulnerability findings) because they are focused on one activity vs. internal teams who are typically pulled into many different security activities.
  2. Work with your vendor to find the best balance between automated scanning and manual testing.
  3. Contextual remediation recommendations. Plus, the development of code libraries that can be leveraged for remediation.
  4. Dynamic reporting via NetSPI’s Penetration Testing as a Service (PTaaS). NetSPI delivers all secure code review results through its PTaaS delivery platform. The platform enables:
    1. Enhanced, real-time reporting
    2. Accelerated remediation
    3. Reduced administrative time
    4. Continuous testing
    5. Faster vulnerability scanning with Scan Monster™, our proprietary continuous scanning technology

Final words

As discussed above, to prevent your organization from falling victim to next major supply chain attack implementing regular secure code reviews is an essential touchpoint. While continuous static analysis checks provide valuable integration in development environment, adoption should be incremental as per your program goals – and without significantly impacting developer workflow. Collecting feedback from SAST tools, customizing rulesets, and adopting manual code review and verification process are all useful contributors to enhance your application security posture.

Start your Secure Code Review Journey with NetSPI
Back

Data Breach Alphabet Soup

Theodore J. Kobus III published his A to Z of Healthcare Data Breaches, which he presented at the annual America Society for Healthcare Risk Management conference. This list may be ideal to use or model your own internal training after for more than just data breaches. Initially I thought of trying to showcase some of them in a silly reference; but I thought it might be too OPAQUE.

O – Overreacting is not going to get you through the event

P – Preparedness is key

A – Accept that it will happen to you

Q – Quit keeping old data

U – Understand the laws that impact your organization

E – Empathize with your customers/patients/employees – how are they going to react to your response?

In all seriousness; Q and A (no pun intended here) are both important and I wanted to point those two out. If you don’t need the data, as an organization you need to ask yourself, “what are we gaining by keeping this data?”  The liability is attached to every piece of information you retain regardless if you use it or not.  Having (and following) data retention policies will limit such a liability. Accepting that it is going to happen, now that’s a hard pill to swallow.;but similar to Emergency Preparedness techniques that many organizations routinely practice.  As they say, practice makes perfect even if you never have to use those techniques.  Organizations that routinely train for various circumstances are the ones best prepared to handle them.  If you accept that a data breach is going to happen, you’ll find yourself equipping and (more importantly) training for how to respond.  Whether you attach this to existing emergency practices or not is not as important as actually having a response.  Many organizations have suffered both from a Public Relations perspective and financially (fines) by their seemingly lack of response. In the end, training staff how to deal with data breaches because you accept that it will happen will yield positive results from a negative situation.  It’s amazing how people remember what to do during emergency situations; I still remember to get under my desk during an earthquake.

Back

Is your Compliance Driven by More Than an Audit?

Preparing for an audit can be one of the best ways to fund and improve your security program, but this “stimulus package” for your compliance effort typically dwindles once an organization completes or passes an audit. I see this happen frequently in recurring or annual audits, but it is particularly relevant with the recent news of Merrick Bank. Specifically, Merrick Bank is suing Savvis for certifying CardSystems Solutions to be Visa CISP compliant prior to a breach that exposed some 40 million payment card records and resulted in $16 million in fines to the card brands. While this is the not the first breach of a PCI-audited company, it is the first one in which the auditor has been sued. The case raises an important question: Who is ultimately responsible for ensuring that a good security program is in place? Here are some simple, yet critical, points to ensure your security program is driven by something more than the audit itself.

  1. Understand the role of the auditor. When preparing or undergoing an information security audit, it’s critical for organizations to consider the role the auditor performs within a security program. This role should never be a member of your security team or a designer/implementer of your security systems; it must be strictly be a reviewer of your security state at a point in time. While some coaching and direction can be good, all decisions and program enhancements must be driven by the organization itself.
  2. An audit is not a design session. If your security program design is heavily based on the initial audit gap report, your program will not be sustainable. Although you and your auditor share the same goal, ensuring you are compliant, your auditor’s coaching will be targeted on one thing—meeting a specific requirement. Your program will then also be designed merely to meet the standard and not take into consideration sustainability, holistic approaches, and integration with existing business requirements.
  3. If you are not 100% ready for the audit, you should not be audited. Because an audit is intended strictly to be an independent review of the security program, if your organization does not feel it can meet all aspects of the audit, you should fix it first. Don’t consider your audit a pass/fail game between you and your auditor. That is not the point of being measured, nor is it a best practice. Plus, any audit that is worth something requires a joint attestation by you and your auditor; if you can’t sign off on it, neither should the auditor.
  4. Aim higher than the compliance requirements alone. Information security is one of those areas where going above and beyond the call of duty can be a good thing. Compliance requirements are meant to be the minimum standard by which you are allowed to operate; strive to exceed them. Don’t budget based on just meeting the requirement, but budget based on what you think is required for your organization to manage risk effectively. Yes, that’s risk, not compliance.

As an information security auditor and advisor, I have seen numerous organizations pour budget and resources into a compliance initiative and then literally stop everything after an audit has been conducted. By conveying the importance of building a program based on security that meets compliance, an organization will be better prepared to defend against breaches and satisfy its auditor at the same time.

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X