Starting, or even refining, a cyber security program can be daunting. Because a security program is as individual as an organization and must be built around business objectives and unique security aspirations, there’s no one-size-fits all solution and the number of tools and services available can overwhelm. The good news is that, if you’re about to embark on a security journey, the following activities will set you on the right path.

Define Your S-SDLC Governance

No matter what security techniques you end up using, you must start by defining your Secure Software Development Lifecycle (S-SDLC) governance security gates and incorporate them into your SDLC. For each gate definition, make sure you collect information needed to determine whether a component passes or fails before the software can advance to the next phase of development. For example, before promoting your application from the coding phase, you might want to do a static analysis scan. If that scan reveals a critical vulnerability, you’ll want to prevent your application from being promoted to the testing phase. Instead, report that vulnerability to the development team, who then must resolve the problem to the degree that the piece of software passes the next static analysis scan without revealing any more critical vulnerabilities. Only then do you advance your application to the testing phase.

For governance rules to be effective, you have to build a collaborative culture within your development organization and communicate and evangelize about these processes. Make sure everyone involved is aware of, and understands, the expectations to which they’re being held.

Secure Design Review

Secure Design Review (SDR) is a broad term with many different definitions. It can refer to high level, pen and paper exercises to see if there are common issues with the application being developed. It can also mean a deep analysis complete with full blown threat models. Or anything in between. Regardless of your approach, SDR allows your organization to catch vulnerabilities at the design level to adopt better security controls. SDR allows organizations to start adopting a culture of security by focusing on developing secure by design frameworks or libraries that create opportunities to efficiently implement re-usable security features as appropriate. A positive outcome? Peace of mind.

Penetration Testing and Security Testing as Part of QA

Penetration testing to assess internal and external infrastructures, often driven (but not exclusively) by governance or compliance regulations, is one of most common activities involved in cyber security programs. Note: It often requires expertise that you might not have inhouse as you get your security efforts underway. Fortunately, there are plenty of firms out there that are really good at it, and outsourcing may be your best option – especially for assets that meet mission-critical risk thresholds. Ultimately, penetration testing’s biggest value for your new security program is that it will reveal just how secure your SDLC is, which you defined in the previous steps.

Security testing is also typically performed by outside experts. However, if you have a group internally who’s already doing some sort of testing – like functional testing or QA testing – it’s easy to introduce basic concepts that allow them to test for vulnerabilities. For example, when your QA testers are building test cases, encourage them to adopt techniques like constantly building edge and boundary test cases. At a bare minimum, this will assess your application from an input validation, and output encoding perspective.

If you’re doing pentesting, look at the results and build test cases based on them into your QA workflow as well. As an example, verbose error messages should be examined. How many times have you tried to log into an app, mistyped the password and received an error message along the lines of: “Your user ID is right, but your password is wrong.” A message like that can give an attacker information they can use to brute force all possible passwords to effectively determine which are valid and which aren’t.

Interactive Application Security Testing (IAST) is gaining popularity quickly and is a rising star amongst application security testing and discovery techniques. Because it is instrumented into running the application on the server side, it can report issues that are truly exploitable, which results in the IAST tool reporting little to no false positives.

Create a Threat and Vulnerability Management Process

To improve your risk posture, it is advisable that organizations create a threat and vulnerability management process. In other words, a process to measure the rate at which you’re identifying vulnerabilities and the rate at which they’re being addressed. Next, create a centralized system to manage the vulnerabilities themselves – and build metrics to be sure you’re getting the right business insights into your program.

Before we go further, let’s clarify what metrics and measurements are, as there can be a lot of confusion around what each term means. Measurement is a fact or number used to quantify something. A metric is usually a combination of measurements, frequently a ratio, that provides business intelligence. For example, “I had three cups of coffee today” is just a measurement. My blood/caffeine ratio, however, would be a metric. The fact that I had three cups of coffee today doesn’t tell me much. But the amount of caffeine in my blood tells me something that might be important.

To take the example a step further, people sometimes will take raw data, such as the number of vulnerabilities found, and use that to measure their success. Wrong! You have to build key performance indicators (KPIs) and key risk indicators (KRIs) that are based on your business risks. Use your KPIs and KRIs to develop metrics that will guide you in your application security journey.

Initially, you might be able to only build metrics on coverage, such as the percentage of your applications portfolio that is currently being tested. Over time you can build more mature metrics to determine things like holistic policy compliance and later, look at effectiveness metrics for things like penetration testing and secure code review. Lastly, when you are heavily focused on remediation and reducing

Develop Application Security Standards

Chances are, you have security policies that you need to adhere to, whether established internally, by regulatory bodies or even customers. It is important to unify them to build application security standards applicable to your business and SDLC practices. Then, enforce them with automation whenever possible. For example, you might want to customize static analysis or dynamic analysis tools so they understand what your standards are. These tools will trigger an alert when a certain security standard isn’t being met.

Various automation tools and techniques are available that can improve the quality and security of the software that you’re implementing, including:

1. SAST – Static analysis security testing
2. DAST – Dynamic application security testing
3. IAST – Interactive application security testing
4. RASP – Real-time application self protection
5. SCA – Software composition analysis

For a deeper dive into these tools, check out this Cyber Defense Magazine article, starting on pg. 65.

Identify and Inventory Open Source Risk

Open source code is everywhere. It’s convenient, replicatable and efficient to use. Many developers employ it. With open source code, however, you need to maintain a heightened awareness of possible security risks.

Maintain an inventory of all open code that you’re using throughout your organization. While those components might not currently pose a risk today, or be known to contain vulnerabilities, some type of zero day vulnerability could be discovered on a particular component. The moment that happens, you need to identify: 1) whether you’re using the component that’s vulnerable, and 2) know where you’re using it and whether your software is now exploitable. You’ll also want to track any possible licensing conflicts as early as possible to avoid legal headaches.

The Longest Journey…

… begins with the first step. If the application security journey you’re about to embark on feels like the epic trek of a lifetime, don’t worry. These six security activities will start you on solid footing and help you navigate along the way.

Nabil Hannan

Application Security is a crucial component to all software development today. At least, it should be as cyber security concerns continue to grow at the same furious pace as the number of apps out there. However, here at NetSPI, we talk with a lot of software development teams who haven’t yet adopted a security mindset, thereby placing not only their programs at risk of cyber-attacks, but their entire organizations as well.

If you’re fighting resistance within your organization to incorporate security measures into the software development life cycle (SDLC), this blog post is for you. We’re going to set straight four of the most common myths and misconceptions we hear among those who don’t have robust application security processes in place.

Myth #1 – An application security team is optional

On the contrary – an application security team today is a must. Someone within your organization should own the function. The good news is that you don’t need a big team to manage it. In fact, we’ve seen programs that work really well with small teams – even teams composed of just one person, in some cases.

Another must: enable an application security culture and nurture that culture across the entire organization, paying special attention to key stakeholders who contribute to your application development lifecycle. Some companies foster an application security philosophy with a security champions program, where leaders in the software applications organization are nominated to advocate on behalf of the application security team. The beauty of this approach is that you have team members within your software engineering organization who can accelerate and fix vulnerabilities quickly. In many cases, they can help reduce the number of vulnerabilities your applications have in the first place. The best side-effect of this approach is that you start organically evangelizing a culture of application security within your organization.

Myth #2 – My organization is too small to have an application security team

This belief is especially common among startups. As intimated above, no organization is too small to focus on application security, mainly because it isn’t just about finding vulnerabilities. You can start by creating governance processes that define security measures and that guide implementation of a secure SDLC, such as:

• Introduce technologies at different points during your SDLC to ensure you capture vulnerabilities early, before a hacker or attacker can exploit your software.
• Integrate security concepts into your software by building application security-specific requirements that become part of your software before a single line of code is even written.
• Create security use cases (also known as misuse and abuse cases) and build functional requirements that focus on security concepts. Then, make sure that your developers have access to those requirements and implement the software against them.
• Educate developers on defensive programming techniques to be able to build software that is naturally resilient to attacks.

Myth #3 – Because we love DevOps and we’re an Agile organization, we can’t have an application security team

Organizations that feel this way usually believe that security teams slow things down. However, security doesn’t have to slow you down when you use the right tools and processes at the right times; and a relatively new concept known as DevSecOps can help. DevSecOps is a culture in which security is integrated between the development and operations functions to close the gap between the development, security, and operations teams, three roles which are historically siloed. If these three roles are required to work more collaboratively, a shared responsibility for application security is created, which enables a DevOps and/or an Agile organization to introduce security as a frictionless component of all processes. Ultimately, the objective is to make security-driven decisions and execute security actions at the same scale and speed as development and operations decisions and actions. To succeed with this approach, an organization must adopt a DevSecOps culture.

Myth #4 – Application security teams will slow us down

As mentioned above, application security doesn’t have to be a hinderance. If you’re using best practices and building good quality software, security is an inherent part of that. Most software performs better and is more efficient when it’s developed securely in the first place. When you adopt a security mindset, your SDLC will flow smoothly, enable you to build better software and can even save you money in the long run.

Getting started with application security:

Best practice dictates the introduction of appropriate touchpoints throughout each phase of your process.

Education, for example, is a good first step:

• Educate your product managers and business analyst(s) on common security vulnerabilities and real-world scenarios of how these security vulnerabilities had a severe impact on an organization, so they can help guide security requirements for your software and always be security conscious.
• Educate developers on defensive programming to make sure they implement software that is naturally resilient against vulnerabilities.
• Educate your teams who are involved with testing and deployment to detect vulnerabilities using various techniques like manual penetration testing, adversarial simulations or red teaming activities.

Learn more about secure code review and building application security into your software development lifecycle.

Second, during the planning phase, create security requirements, or benchmark your program, so that you can understand how mature your organization’s SDLC is, from a security perspective, and so that you can take educated steps to evolve and elevate it over time.

Third, in the design phase, construct your software so that it is naturally resilient to attacks. When you’re building use cases, be sure to add misuse and abuse cases. An example of a misuse/abuse case would be when an attacker tries to “brute force” all possible usernames and passwords into those fields in a login page. You can address such a case by making the software automatically lock an account after multiple wrong tries. You should also create a velocity or anti-automation check to prevent an automated tool and scripts from brute-forcing its way into compromising your application.

During the coding phase, you can not only educate your coders on writing secure code, you also can employ techniques like static analysis, manual code review, and composition analysis to identify vulnerabilities early in your SDLC.

In the testing phase, you have the opportunity to leverage manual penetration testing, dynamic scanning, and build risk-based test cases based on the misuse and abuse cases defined earlier.

Lastly, in the deployment phase, test your detection controls, perform adversarial simulations and red teaming activities. Consider manual penetration testing or implement technologies like RASP to offer continuous protection of an application even if a perimeter is breached.

Because in today’s world software is everywhere – from refrigerators and coffeemakers to medical equipment and data farms – application security is becoming ever-more complex and increasingly critical. Every software development organization, no matter how large or small, must focus on application security to protect its products, the end users and, ultimately its own organization.

For more information, watch my presentation at the recent Cyber Security Summit or contact us to learn how you can get started on your own application security journey.

Nabil Hannan