Many Hands Approach To AppSec

"If you want to frustrate a good developer, interfere with their ability to complete work." - Developers

I've been working in technology for nearly two decades. More than half of that has had software development as one of my primary daily responsibilities. A time I look back on fondly was early in my career, when I developed internal tooling where I owned the flow from requirements gathering to user-acceptance testing. I would sit with the user, and learn their process. Then I would go back to my desk and design a tool to augment that process. During this time, I often had very few status updates or meetings, almost my entire day was me productively building software at my desk. Then I would deploy to the staging environment, inform the user, and see how it worked from them. Once I had some feedback, I would iterate one more time, and then I was typically done with the task. I was relatively autonomous and efficient.

A few short years later, I was working in a large financial institution, and there were a lot more rules. For one thing, those of us in technical roles were forbidden from talking to the users directly.  If I had a question about requirements, it went through a technical system analyst, who talked to a business system analyst, who talked to an end user or someone who represented them. There were similarities to that earlier job in what I was building: a combination of automations and tools for people; but there was a lot more process around it.  If I wanted to install a piece of software on my workstation, even if it was already approved, licensed, and used within the organization, it often took several days. Project managers ran status meetings on a frequent but irregular schedule, and seemed compelled to fill an hour when fifteen minutes would suffice.  Deployments, even to pre-production environments, including QA, required a fairly rigorous change management process.  Overall, it felt like every bit of process and procedure in the organization was diabolically contrived to hinder any momentum in the development process. With all those controls in place, one might expect that the applications were at least more secure.  However, I do not believe that was the case. For one thing, a project reached production, it was usually built on outdated, and often unsupported, libraries and platforms. The process to upgrade any of these was also tangled in bureaucracy. One of the most noteworthy failings of this culture, from a security perspective, was that I saw developers circumvent a variety of controls within the organization, solely for the purpose of completing their work. Perhaps the most egregious was using a privilege escalation flaw to gain temporary local admin rights on the developer workstations.

Through the lens of simply wanting to do the things that we were tasked with, the entire organization felt adversarial. And we treated it as such, to the benefit of our assigned objectives, and sometimes to the detriment of the organization's security.

When we discuss the insider threat within the realm of information security, usually we are talking about a malicious action by a disgruntled or coerced employee, or accidental damage caused by an action. But I think we would be remiss if we overlooked the employee who simply wants to do their job, and feels inhibited to the point that they have to subvert the system to succeed in their responsibilities. I think that goes double when the employee is in a technical role.

My upcoming webcast, The Many Hands Approach to AppSec, draws from my experiences as a developer and system architect, in addition to those over nearly a decade in security consulting, to discuss the core elements and considerations I would have for rolling out an application security program. It has an overarching theme of including people across various roles within the SDLC. I believe that with the right approach, and the necessary dialog, you can foster a culture where the aforementioned potential insider threat, that developer with a deadline, can instead be a deputy in securing the organization's software systems. There is a balance between being judicious in where security practices add friction to the process, and the need to cultivate enthusiasm about security-mindedness across the technical roles. I look forward to seeing you there.

Join us on Thursday September 26th, 2024 at 2:00 PM EDT as Eric and I delve deeper into approaching AppSec. You can sign up here.