True Positives is excited to announce that Brook S.E. Schoenfield has joined the firm to lead our AppSec Assurance Strategy service. His wealth of experience in software security from his days at Cisco and beyond helps him be an industry-leading visionary. It’s a huge value-add to us and our clients.
In this edition of PracticalAppSec he talks about his personal journey alongside the evolution of application security.
Before AppSec, there was InfoSec
20 years ago, application security or “AppSec” didn’t really exist. Sure, we wrote software to avoid common vulnerabilities, like avoiding race condition opportunities and handling program memory in a way that prevented mistakes that attackers could exploit.
Even so, “security” wasn’t a problem for developers, but a separate set of boundaries and access controls.
Security was left to IT departments, with “InfoSec” becoming a discrete and detached team using bespoke tools and methods. Developers were always out of the loop, except for InfoSec’s demand that software is “securely coded”.
History of Software Security
As early as the mid-1970s, some of the first secure design principles were published. NIST 800-14, 1996, stressed that early security requirements needed to be identified. A few thought leaders have been considering software security for a long time.
In the 1990s, several visionaries released works on designing software for security, along with foundational texts that brought design, implementation, and verification into a whole new way of thinking: the proto-Secure Development Lifecycle. (SDL).
The early 00's saw an increase in understanding the depth and breadth of what would eventually become “AppSec” or application security.
Meanwhile, InfoSec was focused on firewalls, network boundaries (segmentation), and intrusion detection. But forward thinkers were starting to tackle the mounting pile of vulnerability reports through:
Reporting structures like CVE
Archives like the U.S. National Vulnerability Database (NVD)
Severity ratings like Common Vulnerability Scoring System (CVSS)
Defining practices like “security architecture”, “incident response” and “forensics”
Still, each new worm infection far overshadowed these forward looking efforts.
Shifting Focus to the Application Level
A few people in the early 00's realized that applications were becoming the preferred target, which offered intruders significant value. The threat landscape was changing to include more application message encapsulated exploits. To meet this growing challenge, security would have to be incorporated as part of developing software in addition to the infrastructure controls that were the focus of security at that time.
Pioneering Application Security
I know this because I was among Cisco InfoSec’s early security architects. I filled InfoSec’s first “application security architect” position. By then, I’d had 16 years of software engineering experience, eventually becoming Director Of Software Development and then a Chief Designer at an independent software vendor. On the side, I also managed that company’s digital security. Cisco Infosec brought me on as an architect because few people in InfoSec had extensive development experience and even fewer had proven software design capability. So, in a very real way, you could say that I grew up as AppSec and its secure design subdomain emerged and matured.
What’s Stayed the Same?
Some software security challenges have remained remarkably consistent over the years:
Vulnerabilities still get released from errors in handling memory. Every single issue called out in Cisco InfoSec’s first C/C++ coding standard still exists today despite billions of dollars invested in scanners that are supposed to find these issues reliably.
Developers continue to believe that the firewall protects their applications, that encryption is an all-purpose security fix, that authentication magically prevents attack, that software security can be equated with secure coding, and that all software security can be automated.
There remains a recurring set of design weaknesses that continue to get deployed with astounding regularity.
The State of AppSec and Today’s Risks
Even with all the advancements in application security thinking and tools, there are still major gaps between stakeholder’s needs and their investments. The stakes are higher than ever, but for many, achieving “Defense in Depth” remains a pipe dream.
Tooling for the Job
The types of tools application security relies on include:
Scanners
Analyzers
Activity Monitors
Protective Devices
Access Controls
And importantly, human analysis
Not only are many needed to build and operate defense at scale, but they need to be constantly improved to meet new threats. And automation tools need to be considered as just one piece of the puzzle, not a “set-it-and-forget-it” solution.
How Holistic AppSec Approaches Help Organizations
Besides tooling, a strategy needs to be developed for the entire organization to be successful at AppSec. Leaders need to be developed, best practices need to be trained beyond just the developers and IT teams, and division of tasks and duties needs to be well understood by all involved. Avoid the finger pointing after a fire by putting this in place throughout your company.
It’s rare that you can just go hire an AppSec expert. These skills aren’t simply a normal part of comprehensive computer science curricula. Most skills are learned on the job, through tons of hard work, and enough mistakes to learn difficult lessons. That’s where we come in.
Why I’m Joining True Positives
Everything I just covered is what the team at True Positives is seeking to help with, which is why I’m proud to join their ranks as the AppSec Assurance Strategist. Together, we can help organizations tool up for reliable automation wherever possible, and set up for long term success in all the areas where automation falls short. In my role, I’ll be responsible for the latter, training leaders in your organization to deploy and maintain best practices across departments, and providing the strategy that helps products, applications, and entire systems be built for security from left to right.
We can train software security, secure design, threat modelling, secure coding, and getting the most out of verification methods and steps. Wherever security tasks lend themselves to automation, and automated delivery is sufficiently effective, we understand what can be automated and how to automate it. At the same time, we can tailor a software security or DevOps security toolchain to deliver on its promises.
We can also augment skills or staff by threat modeling an application or system, providing a secured design, or reviewing an existing design or concept. Finally, we can provide hard-to-hire software security leadership by mentoring and empowering practitioners in your organization to become security leaders in their own right.
True Positives does software security with you and for you, to support you as you strive towards your AppSec requirements and objectives.
Learn more ways we can help you out here.
About Brook S.E. Schoenfield
Brook S.E. Schoenfield is an author, passionate security architect, and curious questioner of assumptions. His books include Secrets Of A Cyber Security Architect (Auerbach, 2019),Securing Systems: Applied Security Architecture and Threat Models (CRC Press, 2015), and Building In Security At Agile Speed (with James Ransome, Auerbach, 2021). Securing systems was a CRC Press best seller in 2020.
About True Positives, LLC.
True Positives (aka T+) is an application security consultancy specializing in test automation and assurance services. We support security teams and toolmakers alike to help the entire industry shift left and beyond.
Website: www.true-positives.com
Email: appsec_solutions@true-positives.com
Call: (360) 557-3918
Practical Tooling, Edition #8, July 2021, True Positives, LLC.
,
