Whitelist Relationships as a Path to Better Security

Implicit deny and explicit allow were two core fundamentals from the start of the information security discipline. However, as the scale and complexity of infrastructures grew, it became evident the list of things we should allow is exponentially smaller than the list of things we should deny. Say "no" to everything unless it is known to be good. This ushered in new technologies like application whitelisting, layer 7 firewalls, and adaptive authentication. Our technology adapted, but how we communicate with teams didn’t. It is now clear we also need to modify our behavior. We need to whitelist our relationships with people. I experienced this recently when I changed companies. I came from an organization that had a lot of internal barriers, axes to grind, and political infighting. Relationships with the security team and other parts of the organization suffered. When I moved to my next role, I learned some hard lessons: just like security technologies had evolved, I needed to evolve how I forge partnerships with people that can improve the security of the organization.

Internal Trusts

Just like we have internal networks and systems that are trusted we should look at some of our internal teams as trusted sources of information. If we can’t treat them as trusted sources, we should look at how our technology has evolved to address the issue. We don’t always deny connections. To address information that could be relevant, but doesn’t have a trust relationship yet, let the connection come into the sandbox and learn what it’s trying to communicate. When building relationships with people a zero trust model is rarely effective. This doesn’t mean we should no longer look critically at past decisions or the answers we are given. What it does mean is we should assume there were reasons for every decision. We should assume internal finance teams, IT teams, and other groups have valuable feedback we can leverage to avoid pitfalls in our security program. There should be an internal trust that is constantly examined and only denied once the trust is violated, not before.

Layer 8 Rules

OSI Layer “8” is Management. You can explain everything from Layer 1 to 7, but if you don’t have management buy-in, you won’t get anywhere. Develop the relationships with management teams first. Work with them to understand what the business needs before trying to engineer a security solution. Oftentimes, critical issues that could kill your new controls could be avoided with a conversation. Creating rules of engagement that facilitate communication with “Layer 8” will help you develop the right controls.

Behavioral Based Security

Security nihilism is accepted too quickly. If we can’t have perfect security, then why bother? Rarely is a security control perfect. We shouldn’t blindly reject improvement. How can we move in a positive direction in regards to securing systems every day? We need to look at behaviors and reinforce positive change. If people know the right thing to do, more often than not, they will do it. When they are generally improving the overall security of the organization, we should encourage the behavior to continue even if it’s not perfect. Information security technology evolved rapidly over three decades; we now need to evolve our relationships. We need to update our methodologies for engaging with our people. Let’s whitelist relationships with our peers and coworkers so we can find a common path to better security.

Image

About the Author: Ean Meyer is an information security professional working in Central Florida. Ean’s current focus areas are PCI, SOX, Intrusion Detection and Prevent Systems, Information Security Program Management, Penetration Testing, and Social Engineering/User Awareness Training. Ean has a BS in Information Security and an AS in Computer Network Systems. Ean also holds a CISSP certification. He can be found at: https://www.eanmeyer.com Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.