Back
Six Activities to Jump Start Your Application Security Journey
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:
- SAST – Static analysis security testing
- DAST – Dynamic application security testing
- IAST – Interactive application security testing
- RASP – Real-time application self protection
- 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.
