DEVELOPMENT

Security to-do lists slow you down, security tools need to fix the problems they find

Mark Maney
Head of Customer Success
December 19, 2022
Mark Maney is an accomplished customer success leader with ties to both civil and computer engineering and has overseen the product lifecycle in product management, development, implementation, and consulting roles. Outside of work, Mark can be found golfing, tinkering, or spending time with his wife, daughter, and energetic Basenji mix.

Security to-do lists are outdated and inundate security professionals with bloated backlogs and alert fatigue. Software supply chain security tools need to provide context, priority, and actionability across all development ecosystem risks and an ability to actively reduce risk through automation.

{{arnica-top-signup-banner="/template-pages/try-arnica-banner"}}

For years, the world of enterprise technology has been filled with cringeworthy catchphrases like “ditch your reports” and “more than a dashboard”, resulting in group eyerolls during sales pitches. The proliferation of these sales references causes industry angst, but there is merit to the context – if not the delivery of these clichés.

Reports have long been seen as one of the least efficient legacy business practices, and for good reason. Reports lack context, require additional investigation to become actionable, and create backlogs of tasks that frequently go unfinished.

As a result, reports evolved from static lists to real-time alerts, dashboards, and finally to prescribed actions, taking us beyond the finding and straight to the solution. In this new process data is translated not into to-do lists, but into directions with appropriate context and actualized resolution. This increases the likelihood of corrective action and reduces response times. One area where this evolution has been less visible is within the security industry, where solutions have remained alert or list oriented, often focusing on reports as an outcome rather than a step in the process of solving risks.

A trailing industry 

Though list-oriented processes are seen as outdated, much of the security world still revolves around audits which result in lists, and nowhere is this more evident than within the list driven process of user access reviews, a periodic and retroactive view of excessive access risks which requires multiple stakeholders and often results in inconsistent action or no resolution at all.  

User access reviews are well intended, designed to secure assets by maintaining least-privilege on a regular basis. The reality, however, is that properly analyzing access requires a level of granularity that cannot be expected through manual efforts, and even organizations with aggressive monthly audit cadences are looking at old data – imagine what can be accomplished over 29 days with stolen access credentials. This approach results in a shallow analysis and delayed response to permissions governance. 

Those who oversee access reviews also face a well-known dilemma: multiple managers are unlikely to adhere to a singular policy definition, but a single auditor lacks the context necessary to determine which privileges are necessary. In many cases the audit is conducted by one team, and then passed to development managers who are expected to know exactly which permissions are needed, leaving many important decisions to each manager. How do you define the “need” for access? Is it their current project’s scope? Their overall role’s responsibility? A combination of both? Each manager is likely to have a different answer. 

Because this list is received differently by each reader and business unit, policy adherence can suffer due to lack of action, rubber stamping, or in the best of scenarios – inconsistent application of policies as action and urgency are defined by the audience.

Solving the problem 

Irregular permissions audits and quarterly access reviews are just a few examples of this problem. Compliance audits, third party vulnerability assessments, and code analysis are all done retroactively, often after the risk has already been introduced. 

These challenges can be overcome by focusing on proactive mitigations rather than retroactively creating lists. An automated and policy-driven approach to security can incorporate more granularity and actively reduce risks before they occur. Continuous analysis ensures fast, accurate, and consistent policy adherence. This means a more secure development ecosystem, more timely and accurate resolution to risks, and less confusion around governance.Without automated processes in place to expedite risk mitigation, vulnerabilities can be exploited while lists change hands, and partial solutions can leave you feeling protected while still at risk. Ultimately, dashboards and fix-it lists are feel-good solutions that just don’t cut it anymore.

THE LATEST UPDATES

More from our blog

What Every Developer Needs to Know About GitHub Branch Protection
What Every Developer Needs to Know About GitHub Branch Protection
September 23, 2024
What Developers Can Learn from Taylor Swift's Re-recording Strategy
What Developers Can Learn from Taylor Swift's Re-recording Strategy
March 25, 2024
How We Converted a GitHub Tool Into a General Purpose Webhook Proxy to Supercharge Our Integration Development
How We Converted a GitHub Tool Into a General Purpose Webhook Proxy to Supercharge Our Integration Development
March 25, 2024

{{arnica-bottom-signup-banner="/template-pages/try-arnica-banner"}}