DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Building Enterprise-Ready Landing Zones: Beyond the Initial Setup
  • Cookies Revisited: A Networking Solution for Third-Party Cookies
  • It’s Not About Control — It’s About Collaboration Between Architecture and Security
  • Hybrid Cloud vs Multi-Cloud: Choosing the Right Strategy for AI Scalability and Security

Trending

  • How To Replicate Oracle Data to BigQuery With Google Cloud Datastream
  • Why We Still Struggle With Manual Test Execution in 2025
  • Scalable System Design: Core Concepts for Building Reliable Software
  • Stateless vs Stateful Stream Processing With Kafka Streams and Apache Flink
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. Acting Like We Care About Security

Acting Like We Care About Security

The final part of a 3-post series on why it's so hard for folks to care about security, and suggestions on ways to get them to start.

By 
Leon Adato user avatar
Leon Adato
·
Oct. 15, 24 · Opinion
Likes (1)
Comment
Save
Tweet
Share
4.1K Views

Join the DZone community and get the full member experience.

Join For Free

This will be my last entry on the topic for a while. For context, I introduced the idea that folks don’t care about security, they care about outcomes in this post; and then I began exploring ways we, as IT practitioners, can shift the focus to the results and therefore contextualize the actions needed as something other than “security for the sake of security.” In this post, I’m continuing with that line of discussion. What can we DO to make our environments more secure, and how can we get our colleagues to understand and want to do it?

Focus on Actual Risks and Realistic Outcomes

(or: Don’t let “perfect” be the enemy of “good”)

When doing your homework to build those aforementioned risk profiles, you need to be open to the possibility that whatever you’re trying to fix doesn’t represent a material risk or isn’t as big of a deal as you initially thought. 

On the other hand, sometimes the risk really *IS* that bad, yet the company seems unwilling to discuss it. There are two things to keep in mind:

  1. Remember that “accept” is one of the options for risk management. The trick is getting someone to sign off on that acceptance formally. Implicit acceptance is the worst kind of risk acceptance and is usually a sign of a communication breakdown. If the best you can get is a verbal “It’ll be fine; you worry too much!” then you might have a much more considerable risk on your hands: 
  2. Second, consider that the organization didn’t really hear (or internalize) what you’ve been saying. They’re refusing to listen now because they haven’t been part of the journey up to this point. Your next step isn’t to throw your hands up but rather to retrace your steps and discover where the disconnect happened. 

I won’t lie; this is where the politics and interpersonal element can be its most frustrating — it’s incredibly difficult to go back and reiterate everything you’ve already said, to go through the act of what feels like smoothing ruffled feathers and soothing fragile egos. But like ANY relationship, communication (and its lack) always sits at the point between moving forward and getting caught endlessly in the past. That doesn’t mean you have to be everyone’s punching bag. But just as I suggested at the beginning of this section, you need to be open to the reality that an issue you perceive to be a risk might not be that big of a deal; so to do you need to be open to the possibility that your first attempt to communicate didn’t work that well, and you need to admit that to everyone and try again.

“We’re from the government, and we’re here to help.”

As I hinted at earlier, NIST is aware of this issue and is attempting to bridge the gap between organizational/leadership goals and objectives and the value that infosec can provide. One of the primary outputs of this effort is the “Integrating Cybersecurity and Enterprise Risk Management” document.

One of the authors, Bob Gardner, calls it “making the connection from the adversary to the wiring closet to the board room.”

This document (along with other content in the 8286 series) underscores NIST’s understanding that what businesses want from cybersecurity is a contribution to risk management in terms of mitigation, avoidance, transfer, etc.

The NIST series extends (and aligns with) an earlier plan, OMB Circular A-123, which directs Federal agencies to develop a formal “risk profile” (sound familiar?) and use it to combat cybersecurity threats. 

But the assistance and insight doesn’t end there. Sometimes, the answer to “what are we supposed to do about this” is hidden within the very security policies and frameworks companies are bound to comply with. Whether you’re talking about HIPAA, PCI-DSS, SOX, GDPR, or any one of the many other acts, provisions, or guidelines; there are usually goals and achievable objectives described. 

In this regard, Samuel Svarc points out: “These schemes don’t mandate specific technical steps (e.g., Advanced AV, password manager, etc.) but rather broad categories of requirements (“company will create reasonable password policies,” “company will take reasonable measures to secure computers from common threats,” etc.) that are open to interpretation… ” and yet provide a reasonably clear path forward. 

Furthermore, Svarc says, “…if a company can show that they conducted a real risk assessment which was then substantially followed, they will be treated differently than a company that didn’t. A company that has a current firewall, Advanced AV on workstations, ZTNA for remote workers, Bitlocker on all laptops, password managers, and FIDO keys with 2FA, normal logging monitored by competent SOC, is in a totally different place security-wise than a company that has laptops running around unencrypted, or without 2FA turned on (to mention two low hanging security steps).” 

Security by Any Other Name

A long-running discussion I’ve had with Kymberlee Price, CEO of Zatik Security, revolves around the definition of security and why we are (or should be) concerned about it at an organizational level. Security continues to be presented as a technology in its own right when, in fact, it’s truly about improving quality. “Quality code,” Price states with the authority of someone who’s spent over 25 years working in the security space, “is reliable. Quality code is secure.” She’s championed for a while, and it’s gaining traction in the industry at large.

Tell a developer their code has a security issue, and you will not likely get more than a passing glance. After all, “shift left” was recognized as corporate double-speak for “one programmer does the work of two people for the same pay,” shortly after Larry Smith coined the term in 2001. Using it to mean developers should test their own code for security only increases the resistance. 

However, tell a developer their code has a quality issue, and you’ll have their full attention. 

“Security is actually quality by a different name” is more than a marketing spin; it’s a message meant for more than the coding crowd. If a business’ processes, policies, or products have overlooked or under-emphasized security, it’s highly likely that other aspects got short shrift as well. And that speaks to low quality. Conversely, if security has been fully considered, it’s far more likely the other aspects have also been reviewed and confirmed — if for no other reason than the fact that the job of security teams is to ensure those elements have been reviewed in the first place. 

What I’m getting at is that security is one of the fundamental aspects of any business, tightly bound to everything from design to delivery. Pretending otherwise and treating security as some completely separate discipline that’s divorced from poor outcomes in success, velocity, and even profitability is how we ended up in the current situation in the first place. 

Summary

It’s difficult, if not impossible, to argue that backups aren’t important for the simple reason that the value they provide (i.e., the ability to restore data) is intuitively obvious to every level of the business, from executives on down. 

Security has failed to enjoy organizational support simply because the methods of creating a secure environment are much more complex, the types of threats are much more varied, and the surety of the outcomes is much less assured. 

In my opinion, this is due to the fact that the focus of so much of the infosec narrative has been on the technology and its delivery. This is equivalent to the backup operators making their case by describing the differences in DAT tapes vs. optical vs cloud or the benefits of full backups vs. incremental vs differential. Again, nobody cares about that stuff. Instead, infosec practitioners should shift their narrative to emphasize the business benefits of quality, resilience, and increased value.

Put succinctly: Nobody cares about security, but they sure as hell care about increasing revenue, reducing cost, and removing risk. Your job is to champion the truth that in order to have those things (revenue, etc) the business needs to invest in security across the organization. 

security

Published at DZone with permission of Leon Adato. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Building Enterprise-Ready Landing Zones: Beyond the Initial Setup
  • Cookies Revisited: A Networking Solution for Third-Party Cookies
  • It’s Not About Control — It’s About Collaboration Between Architecture and Security
  • Hybrid Cloud vs Multi-Cloud: Choosing the Right Strategy for AI Scalability and Security

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!