As the founder of Saltworks Security, a company that specializes in helping firms build end-to-end application security (AppSec) into their software development lifecycle (SDLC), one of the concerns I frequently hear from organizational stakeholders seeking robust AppSec is, “How do we go about it?” Increasingly, corporate decision makers recognize that they should apply AppSec best practices to their development and testing processes or face the odds of financial ruin with a major hack or breach. They simply have no idea what or how to get going.
Developing a robust, highly functional and intuitive AppSec program isn’t quick or easy, which is why companies pay Saltworks to do it for them. Nevertheless, the alternative is potential catastrophe. In this article, I will demystify the design process for a best-practices AppSec program by outlining the core framework. But first, a little bit of background.
Where We Are Is Scary
The confusion over today’s AppSec requisites isn’t surprising, given the way that software engineering has evolved over the decades. In many firms, outdated approaches are still being applied to newer development models, or archaic mindsets are rejecting the realities of today’s operating environments. As a result, even dedicated security teams can be challenged by the process of integrating AppSec throughout their software processes.
In its 2016 “State of Application Security: Skills, Configurations and Components,” the SANS Institute noted that AppSec is “maturing for most organizations.” Yet, the study found that only 26% of respondents said their programs were “Mature” or “Very Mature,” and only 17% felt they had fully integrated AppSec into their overall security, risk management, and incident response programs.
I recently provided expert input for a white paper dealing with AppSec for SAP customizations that provides a considerable amount of granular detail relevant to any AppSec effort. (You can read it, here.) Here’s an excerpt that describes some of the more common scenarios that play out in many firms—even those that have some form of AppSec program in place.
- The security team implements the plan it feels will work and tries to force developers to work within it, but it isn’t compatible with the developer’s workflow. Under pressure to meet expedited deadlines, developers dismiss the plan as too complicated or time consuming and attempt homegrown solutions or simply do nothing.
- The security team, anxious to get solutions flowing, issues reports without vetting them. Developers don’t have any guidance regarding priorities and become even more reluctant to act.
- Application testing happens as specified and vulnerabilities are found, but nothing gets done due to lack of time, willingness, an appropriate plan, and/or ranking of vulnerabilities by importance.
In all of these scenarios, application security is neither efficient nor effective. Frustration mounts as security efforts impede the speed, integration, and automation expected in the SDLC of modern applications. Developers (and/or corporate stakeholders) perceive security as a barrier to innovation. The organizational approach continues to be, “Find and fix (and often ignore) errors in production,” or the program is abandoned altogether.
Unfortunately, the harsh reality—as more and more organizations are discovering—is that after-the-fact mitigation of security flaws discovered in production can literally result in corporate disaster. Just ask Equifax. For those firms with little to no AppSec maturity, the situation is more critical. Fixes tend to be reactive, occurring as they are discovered by team members or, worse, reported by users or uncovered after a breach.
Designing an AppSec Program and Processes
The design process has three definitive stages:
- Phase 1: Creating the Software Security Program
- Phase 2: Tooling the Program
- Phase 3: Securing Ongoing Operations
Each of these phases plays an important role, and none can be skipped or cut short. AppSec isn’t something you can develop and turn on, then walk away. It’s like a car or an airplane. It requires continual maintenance and updates if it is to run effectively and not crash and burn.
Phase 1: Creating the Software Security Program (SSP)
In the first phase, security consultants work stakeholders—client security professionals, developers, and other stakeholders to create a plan for the SSP. (In our engagements, we recommend adherence to HITRUST standards.) Elements of the plan include:
- Identify necessary modifications of policies and procedures;
- Create an implementation plan and timeline for methodologies and technologies, such as static and dynamic analysis, penetration testing, and threat modeling, with implementation sequence being driven by client priorities and risk factors.
- Address and plan for additional issues valid to the particular engagement, potentially including such elements as encryption at rest and in transit, logging, and security information and event management (SIEM) activities.
- Determine developer training standards.
Once the elements of the program and their implementation path have been determined, a crucial step of the first phase is to effectively communicate the plan to, and gain buy-in from, developers, the security team and business stakeholders, as well as peripheral staff that will be affected by the program. Changing corporate culture can be far more difficult than developing processes and modifying procedures, especially ingrained resistance to change or territorialism is exhibited by various groups.
Phase II: Tooling
During this phase, all the software solutions that will be doing behind the scenes work are implemented and configured to support the SSP. Staff who will be responsible for using these solutions to adhere to the program are also trained at this time.
The universe of solutions includes, not only the tools used for proactive AppSec, but also the specialized work to assimilate them with the firm’s software development lifecycle, such as integration with defect tracking systems. This phase should end with a Proof of Value (POV) model to determine the software quantities that will be purchased initially and for ongoing support.
Phase III: Cementing the Practice and Ongoing Operation
This phase begins with the launch of the Application Security Operations Center (ASOC)—the heart of the effort—and continues as it is operated and supported by the team. It requires an ongoing effort by a high-level application security engineer (either in-house or outsourced) to mentor and monitor development staff as it implements the SSP, and work closely with developers and other organizational stakeholders to support the training and cement the practice.
The application security engineer ensures the following activities are confirmed and operating as specified:
- Full integration of the SSP into software development lifecycles.
- Continued assessment and remediation as an integral part of development processes.
- Adherence to security best practices for development architectures and application development efforts.
- Adherence to security policies for all application development activities
- Application scanning (dynamic; static) is integrated as part of the build process.
At this point, current and future success also hinges on organizational security experts or consultants creating reports that tracking key metrics of the secure SDLC program. There must also be ongoing build scan reviews to confirm false positives are addressed and have been removed.