How To Get Smarter By Making Distinctions

"Whatever you do in life, surround yourself with smart people who'll argue with you." -- John Wooden

There’s a very simple way to get smarter.

You can get smarter by creating categories.

Not only will you get smarter, but you’ll also be more mindful, and you’ll expand your vocabulary, which will improve your ability to think more deeply about a given topic or domain.

In my post, The More Distinctions You Make, the Smarter You Get, I walk through the ins and outs of creating categories to increase your intelligence, and I use the example of “fat.”   I attempt to show how “Fat is bad” isn’t very insightful, and how by breaking “fat” down into categories, you can dive deeper and reveal new insight to drive better decisions and better outcomes.

I’m this post, I’m going to walk this through with an example, using “security” as the topic.

The first time I heard the word “security”, it didn’t mean much to me, beyond “protect.”

The next thing somebody taught me, was how I had to focus on CIA:  Confidentiality, Integrity, and Availability.

That was a simple way to break security down into meaningful parts.

And then along came Defense in Depth.   A colleague explained that Defense in Depth meant thinking about security in terms of multiple layers:  Network, Host, Application, and Data.

But then another colleague said, the real key to thinking about security and Defense in Depth, was to think about it in terms of people, process, and technology.

As much as I enjoyed these thought exercises, I didn’t find them actionable enough to actually improve software or application security.  And my job was to help Enterprise developers build better Line-Of-Business applications that were scalable and secure.

So our team went to the drawing board to map out actionable categories to take application security much deeper.

Right off the bat, just focusing on “application” security vs. “network” security or “host” security, helped us to get more specific and make security more tangible and more actionable from an Line-of-Business application perspective.

Security Categories

Here are the original security categories that we used to map out application security and make it more actionable:

1. Input and Data Validation
2. Authentication
3. Authorization
4. Configuration Management
5. Sensitive Data
6. Session Management
7. Cryptography
8. Exception Management
9. Auditing and Logging

Each of these buckets helped us create actionable principles, patterns, and practices for improving security.

Security Categories Explained

Here is a brief description of each application security category:

Input and Data Validation
How do you know that the input your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing. Consider constraining input through entry points and encoding output through exit points. Do you trust data from sources such as databases and file shares?

Authentication
Who are you? Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password.

Authorization
What can you do? Authorization is how your application provides access controls for resources and operations.

Configuration Management
Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues.

Sensitive Data
How does your application handle sensitive data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores.

Session Management
How does your application handle and protect user sessions? A session refers to a series of related interactions between a user and your Web application.

Cryptography
How are you keeping secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.

Exception Management
When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?

Auditing and Logging
Who did what and when? Auditing and logging refer to how your application records security-related events.

As you can see, just by calling out these different categories, you suddenly have a way to dive much deeper and explore application security in depth.

The Power of a Security Category

Let’s use a quick example.  Let’s take Input Validation.

Input Validation is a powerful security category, given how many software security flaws and how many vulnerabilities and how many attacks all stem from a lack of input validation, including Buffer Overflows.

But here’s the interesting thing.   After quite a bit of research and testing, we found a powerful security pattern that could help more applications stand up to more security attacks.  It boiled down to the following principle:

Validate for length, range, format, and type.

That’s a pithy, but powerful piece of insight when it comes to implementing software security.

And, when you can’t validate the input, make it safe by sanitizing the output.  And along these lines, keep user input out of the control path, where possible.

All of these insights flow from just focusing on Input Validation as a security category.

Threats, Attacks, Vulnerabilities, and Countermeasures

Another distinction our team made was to think in terms of threats, attacks, vulnerabilities, and countermeasures.  We knew that threats could be intentional and malicious (as in the case of attacks), but they could also be accidental and unintended.

We wanted to identify vulnerabilities as weaknesses that could be addressed in some way.

We wanted to identify countermeasures as the actions to take to help mitigate risks, reduce the attack surface, and address vulnerabilities.

Just by chunking up the application security landscape into threats, attacks, vulnerabilities, and countermeasures, we empowered more people to think more deeply about the application security space.

Security Vulnerabilities Organized by Security Categories

Using the security categories above, we could easily focus on finding security vulnerabilities and group them by the relevant security category.

Here are some examples:

Input/Data Validation

• Using non-validated input in the Hypertext Markup Language (HTML) output stream
• Using non-validated input used to generate SQL queries
  Relying on client-side validation
• Using input file names, URLs, or user names for security decisions
• Using application-only filters for malicious input
• Looking for known bad patterns of input
• Trusting data read from databases, file shares, and other network resources
• Failing to validate input from all sources including cookies, query string parameters, HTTP headers, databases, and network resources

Authentication

• Using weak passwords
• Storing clear text credentials in configuration files
• Passing clear text credentials over the network
• Permitting over-privileged accounts
• Permitting prolonged session lifetime
• Mixing personalization with authentication

Authorization

• Relying on a single gatekeeper
• Failing to lock down system resources against application identities
• Failing to limit database access to specified stored procedures
• Using inadequate separation of privileges

Configuration Management

• Using insecure administration interfaces
• Using insecure configuration stores
• Storing clear text configuration data
• Having too many administrators
• Using over-privileged process accounts and service accounts

Sensitive Data

• Storing secrets when you do not need to
• Storing secrets in code
• Storing secrets in clear text
• Passing sensitive data in clear text over networks

Session Management

• Passing session identifiers over unencrypted channels
• Permitting prolonged session lifetime
• Having insecure session state stores
• Placing session identifiers in query strings

Cryptography

• Using custom cryptography
• Using the wrong algorithm or a key size that is too small
• Failing to secure encryption keys
• Using the same key for a prolonged period of time
• Distributing keys in an insecure manner

Exception Management

• Failing to use structured exception handling
• Revealing too much information to the client

Auditing and Logging

• Failing to audit failed logons
• Failing to secure audit files
• Failing to audit across application tiers

Threats and Attacks Organized by Security Categories

Again, using our security categories, we could then group threats and attacks by relevant security categories.

Here are some examples of security threats and attacks organized by security categories:

Input/Data Validation

• Buffer overflows
• Cross-site scripting
• SQL injection
• Canonicalization attacks
• Query string manipulation
• Form field manipulation
• Cookie manipulation
• HTTP header manipulation

Authentication

• Network eavesdropping
• Brute force attacks
• Dictionary attacks
• Cookie replay attacks
• Credential theft

Authorization

• Elevation of privilege
• Disclosure of confidential data
• Data tampering
• Luring attacks

Configuration Management

• Unauthorized access to administration interfaces
• Unauthorized access to configuration stores
• Retrieval of clear text configuration secrets
• Lack of individual accountability

Sensitive Data

• Accessing sensitive data in storage
• Accessing sensitive data in memory (including process dumps)
• Network eavesdropping
• Information disclosure

Session Management

• Session hijacking
• Session replay
• Man-in-the-middle attacks

Cryptography

• Loss of decryption keys
• Encryption cracking

Exception Management

• Revealing sensitive system or application details
• Denial of service attacks

Auditing and Logging

• User denies performing an operation
• Attacker exploits an application without trace
• Attacker covers his tracks

Countermeasures Organized by Security Categories

Now here is where the rubber really meets the road.  We could group security countermeasures by security categories to make them more actionable.

Here are example security countermeasures organized by security categories:

Input/Data Validation

• Do not trust input
• Validate input: length, range, format, and type
• Constrain, reject, and sanitize input
• Encode output

Authentication

• Use strong password policies
• Do not store credentials
• Use authentication mechanisms that do not require clear text credentials to be passed over the network
• Encrypt communication channels to secure authentication tokens
• Use HTTPS only with forms authentication cookies
• Separate anonymous from authenticated pages

Authorization

• Use least privilege accounts
• Consider granularity of access
• Enforce separation of privileges
• Use multiple gatekeepers
• Secure system resources against system identities

Configuration Management

• Use least privileged service accounts
• Do not store credentials in clear text
• Use strong authentication and authorization on administrative interfaces
• Do not use the Local Security Authority (LSA)
• Avoid storing sensitive information in the Web space
• Use only local administration

Sensitive Data

• Do not store secrets in software
• Encrypt sensitive data over the network
• Secure the channel

Session Management

• Partition site by anonymous, identified, and authenticated users
• Reduce session timeouts
• Avoid storing sensitive data in session stores
• Secure the channel to the session store
• Authenticate and authorize access to the session store

Cryptography

• Do not develop and use proprietary algorithms (XOR is not encryption. Use platform-provided cryptography)
• Use the RNGCryptoServiceProvider method to generate random numbers
• Avoid key management. Use the Windows Data Protection API (DPAPI) where appropriate
• Periodically change your keys

Exception Management

• Use structured exception handling (by using try/catch blocks)
• Catch and wrap exceptions only if the operation adds value/information
• Do not reveal sensitive system or application information
• Do not log private data such as passwords

Auditing and Logging

• Identify malicious behavior
• Know your baseline (know what good traffic looks like)
• Use application instrumentation to expose behavior that can be monitored

As you can see, the security countermeasures can easily be reviewed, updated, and moved forward, because the actionable principles are well organized by the security categories.

There are many ways to use creating categories as a way to get smarter and get better results.

In the future, I’ll walk through how we created an Agile Security approach, using categories.

Meanwhile, check out my post on The More Distinctions You Make, the Smarter You Get to gain some additional insights into how to use empathy and creating categories to dive deeper, learn faster, and get smarter on any topic you want to take on.