Building a Security Program That Scales

Not long ago, an innovative startup company reached out to us with a very specific request – they needed to create a scalable, lightweight program that analyzes security risks during each step of the software development lifecycle (SDLC) and they wanted our help. The company’s goal was to employ a risk-driven approach to security while their products were still early in the development process.

We were thrilled to see the customer thinking about how to fortify their internal development processes and build security in from the ground up. We partnered with the company to create a repeatable testing program they could use internally for all their projects in development. The program needed to analyze security risks during each step of the SDLC and work across a wide variety of projects. Through small internal initiatives over many months, we were able to improve on the organization’s existing security processes.

“The program helped in all the areas we expected,” said the client’s VP of security engineering, “but we didn’t anticipate the cultural shifts we’ve seen internally. Suddenly, other teams were coming to us about security advisories and were asking for our input on how we can better the security in our products, beyond just these assessments.”

ACCESSING SERVICE ATTRIBUTES AND SECURITY RISKS

To create a framework that would scale, Bishop Fox consultant Chris Surage augmented the client’s security engineering team to build out a multi-faceted data model that would track attributes associated with a product or service. With better visibility into these assets through a single tracking system, the team was able to begin assessing the security and risk of each product. The three main attributes analyzed were:

Data types stored or processed by the application or service (sensitive customer data carries a higher threat risk)

Network connectivity (Is this an externally facing application?)

Impact to the business (Would the company lose money if the product or service stopped working?)

Using these attributes, the security engineering team assigned each asset a risk score to ascertain its impact to the organization. By qualitatively measuring the security impact, the team could now define the security requirements needed for each asset. This pragmatic approach to application security ensured a balance between the technical debt of the development teams; and the confidentiality, integrity, and availability of sensitive data at rest and in transit.

With that basic framework in place, Bishop Fox collaborated with the client’s security engineering team to create a testing schedule based on a prioritized list of assets. With this prioritized list, the internal security engineering team could now begin to take a proactive approach to testing and begin to schedule discussions and engagements with development teams.

STANDARDIZING THE SECURITY ASSESSMENT EXPERIENCE

As a holdover from their startup days, many of the client’s internal processes were ad hoc and reactionary and needed to be standardized so they could work at scale across their multiple development teams. Often when security auditing and risk assessments are added to the development process, security teams and consultants are fighting against developers and product teams who are just trying to get a product out the door by a deadline.

Bishop Fox worked with the internal security engineering team to develop a structured testing and reporting process. The procedures included:

• A kick-off call
  • Assessment scoping
  • Status updates
• Report delivery
  • Report creation
  • Peer review
• Post-Engagement activities
  • Creating and assigning findings via JIRA
  • Retesting of security issues
  • Closing remediated tickets

Revamping the process and providing full transparency to the development teams allowed the security engineering team to ensure that the new testing program would be adopted quickly and universally. This partnership between development and security teams cemented the notion that the security function needed to be embedded in the development process.

BECOMING PROACTIVE WITH TESTING AND CREATING SECURITY REQUIREMENTS

After conducting a few assessments, the security engineering team quickly realized that not all were the same and a single standardized process wouldn’t work. So, the framework needed to be more agile to adapt to suit every need. The next iteration involved restructuring some of the procedures created during original test to adapt to different assessment types based on their unique goals: source code reviews, technical security assessments, vendor assessments, and threat models.

During this collaboration with Bishop Fox, the client’s security team also needed to create a baseline of security requirements corresponding to the calculated risk of the application or service. Chris Surage, the Bishop Fox consultant, collaborated with the security engineering team and the incident response team to develop a list of security requirements. These requirements encompassed a variety of design and procedural constraints, such as source code deployment, access logging, and network connectivity. This baseline was used successfully with a business-critical pilot service the client was rolling out. The result was an exercise in how the security engineering team could foster collaboration with different departments to improve the business’s security posture.

With the first test case of rolling out risk-based security requirements successfully completed, the client now had procedures for a mass rollout of security checklists, which all applications and services would adhere to.

APPLYING A SECURITY PROGRAM THAT MAKES A DIFFERENCE

While other members of the organization focused on innovative biometric identity verification and delivering a superior customer experience, the security team must advise leadership and educate employees about secure software development lifecycles (SSDLC), security requirements, and incident response procedures. While embedded in the client’s security team, Chris advised them on strategies to increase participation in their security culture and advocated on behalf of the team to grow that internal support.

A good security program on paper can only accomplish so much if its lessons aren’t integrated into the company. For the client’s security team, the benefits of this collaboration have gone far beyond security improvements in products and applications – security has become an integral part of every team’s workflow.

As the head of a team that affects many aspects of the business, the security engineering team lead worked to leverage the resources of existing departments to gather information in a central hub and increase support for his team by showing the value of his work. The risk-defining framework and the assessment procedures that Chris and the client’s team lead developed helped make the case to increase the security engineering team’s size to scale along with the company’s growth. With increased visibility into assets, priorities, and issues to address, the client could focus on growing their security team consistently with the support of their peers.

With the organization’s leadership supporting the program and openly sharing the immediate value of the team’s efforts with the company at-large, security has really become a part of the corporate culture. With buy-in throughout the company, the security program can continue to evolve with focus and input from all affected departments for the betterment of their customers.

The result is that the product, development, and security teams came together to build a methodology that:

• Worked for all teams involved,
• Didn’t slow down the development process,
• Scaled and adapted to all product development projects, and
• Protected customers, partners, and data.

Senior Security Consultant Chris Surage has made the value and importance of security more visible for the client’s employees. With this solid infrastructure in place and a healthy security culture, they can continue delivering their streamlined services to customers with confidence.