Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Analytics

8/10/2016
01:30 PM
Joshua Goldfarb
Joshua Goldfarb
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
50%
50%

Theory Vs Practice: Getting The Most Out Of Infosec

Why being practical and operationally minded is the only way to build a successful security program.

One of my favorite quotes states: “In theory, theory and practice are the same. In practice, they are not.” I adore this quote for many reasons, and it is one that truly speaks to me. Perhaps I am so fond of this quote because it describes how I approach the discipline of security, and perhaps even life in general.

In my experience, there are two fundamental perspectives that drive how an individual or an organization approaches security: theorist and pragmatist. I’d like to illustrate the difference between these two perspectives through four distinct and examples.

Example 1: Program of “no” 
In many organizations, security has the unfortunate reputation of being the program of “no.”  While it is true that the security organization is ultimately responsible for mitigating and minimizing risk to the organization, it is seldom the case that this is accomplished by saying no all the time.

Let’s take the move to the cloud as an example. In some organizations, the security team will fight the business every step of the way as it moves to the cloud. In other organizations, the security team will work collaboratively with the business to understand how to mitigate additional risk that may be introduced into the organization, work to maintain visibility into business functions that move to the cloud, and ensure that the ability to respond to an incident remains intact.

Why do some organizations take the first approach, while others take the second approach? The former is the theorist’s approach, while the latter is that of the pragmatist. In theory, a move to the cloud will introduce additional risk to the business that the security team may not be able to mitigate. But in practice, the move to the cloud will happen whether we like it or not, and we can either get ahead of it, or be the program of “no”. 

I’ll leave it to you to judge which approach is more likely to help you build bridges and relationships that will allow you to improve the overall security posture of the organization in the long run.

Example 2: Passwords 
As much as we all love 20-character passwords with four capital letters and three special characters, they aren’t particularly effective as a security measure. Of course passwords should not be easily guessable. They shouldn’t be names, birthdays, words, etc. But organizations often take this best practice to a draconian extreme.

What’s the result? Employees write down their passwords or otherwise find ways to work around the system. Using a less extreme password requirement with two factor authentication is usually a much better approach, and it’s one that employees don’t feel the need to work around.

Why do some organizations take the password game to the draconian extreme? You guessed it -- it’s the theorist versus the pragmatist again. In theory, an attacker could guess a password with only 10 characters, one uppercase letter, and one special character more easily than a draconian extreme password. 

But in practice, they don’t:  they compromise systems through the use of social engineering and then steal them. If you insist on being a draconian theorist, you will drive your users to work around you. If you take a pragmatist’s approach, you will find your users much more likely to adhere to your policy.

In other words, by being practical, you are much more likely to achieve your desired results.

Example 3: Anomaly Detection 
Anomaly detection is something I hear people discuss quite often. Back in 2005, I tried implementing a few different anomaly detection solutions that were “guaranteed to work” on a live, production network. What was the result? After a two-week learning period, within the first five minutes of turning on alerting, the solutions generally produced hundreds of thousands of false positive alerts, subsequently flooding and crashing the SIEM.

In theory, anomaly detection is extremely important. I need to learn what is normal, expected, and desired in order to find what is not normal, unexpected, and undesired. In practice, a live, production network is almost never like a lab network, and the flood of false positives and its destructive effect on the workflow and efficiency of the security organization vastly outweigh any potential gain in the detection of malicious or suspicious activity.

Do I think that anomaly detection ultimately has a future in the security field? Absolutely, but only if it is approached pragmatically, with an understanding of, and appreciation for, the pain of operational personnel.

Example 4: I might miss something
I’ve written many times about the need to collect fewer data sources of higher relevance to security operations. In a nutshell, collecting every source of data we can get our hands on, irrespective of its relevance to security operations actually reduces the security posture of an organization in three ways:

  • The variety of data sources creates confusion, uncertainty, and inefficiency. This makes an analyst’s first question “Where do I go to get the data I need?” rather than “What questions do I need to ask of the data?”
  • The volume and velocity of the data deluge the collection system, thereby making data irretrievable in a timely manner
  • Storage is consumed more quickly, thus shortening retention and negatively impacting visibility

In other words, a focus on data value (specifically to security operations), rather than data volume produces better results. Choose the fewest number of data sources that provides you with the required visibility. The theorist believes that he or she might miss something. The pragmatist knows that if he or she cannot leverage the data when they need it most, they will definitely miss something.

It is extremely important to be practical and operationally minded when planning, implementing, and improving a security program. It is important to understand the real-world ramifications and effects that certain decisions will have. While many ideas sound great in theory, in practice, they often turn out to disappoint or even have the opposite of their intended effect.

Related Content:

 

 

Josh (Twitter: @ananalytical) is an experienced information security leader who works with enterprises to mature and improve their enterprise security programs.  Previously, Josh served as VP, CTO - Emerging Technologies at FireEye and as Chief Security Officer for ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
How Security Vendors Can Address the Cybersecurity Talent Shortage
Rob Rashotte, VP of Global Training and Technical Field Enablement at Fortinet,  5/24/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-7068
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7069
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have a type confusion vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7070
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7071
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.
CVE-2019-7072
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .