Recently I was challenged with applying some of the more critical components of SSA to what was termed as a "one man show" (or "one person show" to be totally correct).
Thinking about down-scaling an enterprise security challenge into a smaller fit proved far from easy.
This manifested as more of a challenge than you'd think because it's just too easy to say 'outsource it all'... but how does that actually help an organization write more secure software?
The answer is that it doesn't... so over the next few posts I'll go over the challenges and some opportunities in cases like this - and as always if you are living this situation drop me a note and tell me your experiences and share with your colleagues!
The Organization
The key to talking about a situation is making sure that everyone understand the problem.
Too often I've found myself talking about what I feel is a great solution to a problem posed, in a group, where all of us understood the problem slightly differently... so here is a brief definition of the type of organization I'm addressing.
- Security Resources: 1 (or few) security engineer(s) responsible for multiple roles within the security context both operational as well as advisory. This may include patching, firewall management, policy creation and application security 'testing'. Key here is that there are no dedicated resources for managing, or staffing the various roles and responsibilities or tasks of an SSA program.
- Budget Resources: little (or virtually none) budget dedicated to 'SSA' ...but may have a budget for tools related to 'application security testing'
- Number of Applications: "moderate" (>10...100 ...or so)
- Executive Visibility: Typically executive visibility of risk is low ...or none.
- Organizational Buy-in: Minimal ...typically viewed as security's job, or just a function of arbitrary compliance with minimal standards - not actual security
The Challenge
The main challenge here is getting beyond the hamster-wheel situation I've discussed before. What generally happens in situations like this (from experience, ahem) is the following (usually in this order):
- security concerns are ignored by management, applications released without security purview
- organization fails audit (application security is a, failure)
- organization panics, tells 'security' to go fix the problem (no budget)
- security defines proposal for an SSA program
- leadership rejects proposal, 'do the minimum' instead
- security purchases scanning tool (SAST or more likely DAST)
- security is a 'final checkbox' in a project pre-go-live
- 'scanning' is done, apps fail but are pushed through
- no measurable gains in application security or risk mitigation
This probably looks familiar, doesn't it. If you've felt this challenge before stick around, the next posts will directly address some of the issues that you face, and how to get you off the hamster-wheel and get you into a situation where you're actually helping the organization meet the challenges, and meet your goals as well.
Coming up...
- Rationalizing business goals vs. security goals in a 'small shop'
- Meeting the resource challenges of SSA in a 'small shop'
- Implementing holistic SSA (mentality not 'tools')
- Implementing technology
- Measuring and proving success