• Skip to main content
  • Skip to after header navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Books
  • Archives
  • JD Meier.com

Security Threats and Countermeasures Framework

Apr 7, 2008 by JD

Security Threats and Countermeasures Framework

“Security is not a product, but a process. It’s the way we think about things, the way we reason and the way we approach problems.” — Bruce Schneier

The Security Threats and Countermeasures Framework is a comprehensive and organized approach to software security, utilizing Security Hot Spots to address common vulnerabilities and promote best practices.

During my time working on software security guidance at Microsoft, I developed a framework known I call the Security Threats and Countermeasures Framework, which proved to be a valuable tool for organizing and prioritizing software security issues.

I used this Security Threats and Countermeasures framework to organize and structure actionable security knowledge in the form of guidelines and checklists.

I also used it to help build better evaluation criteria to identify key security decisions that could have a significant impact.

The Security Threats and Countermeasures Framework allowed everyone to collaborate better and to provide a more comprehensive approach to improving web application security.

Ultimately the Security Threats and Countermeasures Framework makes it easier for developers and security professionals to understand and implement best practices in software security.

Security Threats and Countermeasures “Hot Spot” Categories

Over time, I discovered a method to organize our security principles, patterns, and practices into actionable categories that could group patterns of security knowledge into themes.

By focusing efforts around related concepts, these themes helped make security knowledge more actionable.

I referred to these categories as Security Hot Spots and used them as the backbone for the Security Threats and Countermeasures Framework. Here are the Security Hot Spots that were used:

Category Key Considerations
Auditing and Logging Who did what and when? Auditing and logging refer to how your application records security-related events.
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.
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?
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?
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.

Threats and Attacks Organized by the Security Threats and Countermeasures Framework

With the Security Frame, it’s easy to walk the categories and think of potential security problems.  Here’s a list of potential software performance problems, organized by the Security Frame:

Category Threats
Auditing and Logging
  • User denies performing an operation.
  • Attacker exploits an application without trace.
  • Attacker covers his tracks.
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.
  • Over-privileged process and service accounts.
Cryptography
  • Loss of decryption keys.
  • Encryption cracking.
Exception Management
  • Revealing sensitive system or application details.
  • Denial of service attacks.
Input and Data Validation
  • Buffer overflows.
  • Cross-site scripting.
  • SQL injection.
  • Canonicalization attacks.
  • Query string manipulation.
  • Form field manipulation.
  • Cookie manipulation.
  • HTTP header manipulation.
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.

Vulnerabilities Organized by the Security Threats and Countermeasures Framework

You can also use the Security Threats and Countermeasures Framework to identify common mistakes that lead to the security problems above.   Here’s a list of common design mistakes we find in applications:

Category Vulnerabilities
Auditing and Logging
  • Failing to audit failed logons.
  • Failing to secure audit files.
  • Failing to audit across application tiers.
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.
  • Inappropriate isolation levels
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.
Crytpography
  • 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.
Input and Data Validation
  • Using non-validated input in the 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 database, file shares, and other network resources.
  • Failing to validate input from all sources including cookies, query string parameters, HTTP headers, databases, and network resources.
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 identifies over unencrypted channels.
  • Permitting prolonged session lifetime.
  • Having insecure session state stores.
  • Placing session identifies in query strings.

Countermeasures Organized by the Security Threats and Countermeasures Framework

Here’s a list of common design strategies organized by the Security Threats and Countermeasures Framework that lead to improved security:

Category Countermeasures
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.
  • Avoid distributed coherent caches.
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 privileged accounts.
  • Consider granularity of access.
  • Enforce separation of privileges.
  • 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.
Configuration Management
  • Use least privileged service accounts.
  • Do not store credentials in clear text.
  • Use strong authentication and authorization in administrative interfaces.
  • Do not use the Local Security Authority (LSA)
  • Avoid storing sensitive information in the Web space.
  • Use only local administration.
Cryptography
  • Do not develop and use proprietary algorithms (XOR is not encryption. Use platform-provided cryptography.)
  • use platform features for generating random numbers over rolling your own.
  • Avoid key management. For example, in Windows use 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.
Input and Data Validation
  • Do not trust input.
  • Validate input: length, range, format, and type.
  • Constrain, reject and sanitize input.
  • Encode output.
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.

Leverage the Security Threats and Countermeasures Framework to Make Security More Accessible and Actionable

The Security Threats and Countermeasures Framework, along with the Security Hot Spots, have proven to be valuable tools in advancing software security.

By identifying and categorizing security threats and countermeasures, organizations can better prioritize and focus their efforts on the most critical security issues.

As the security landscape continues to evolve, it is crucial to continue refining and updating these frameworks to ensure they remain relevant and effective in addressing new and emerging threats.

By implementing these frameworks and staying vigilant, organizations can better protect themselves and their customers from the increasing threats of cyber attacks.

You Might Also Like

Security Hot Spots for Organizing Security Knowledge
Performance Threats and Countermeasures Framework
Threats, Attacks, Vulnerabilities and Countermeasures

Category: Frames, SecurityTag: Security

About JD

Previous Post:Context PrecisionContext Precision: To Create More Clarity and Relevance, Get More Specific
Next Post:Security Principles

Reader Interactions

Trackbacks

  1. Security Principles says:
    Apr 7, 2008 at 3:50 pm

    […] make the principles more useful, we organized them using our Security Frame.  Our Security Frame is a set of actionable, relevant categories that shape your key […]

  2. Secure Your Network, Host, and Application | Security | Patterns and Practices for Software Engineering. says:
    Apr 13, 2008 at 10:33 pm

    […] We used these categories to organize our application threats, attack, vulnerabilities and countermeasures.  We then structured our guidelines using these categories.  This was the early foundation for our Security Frame. […]

Sidebar

Recent Posts

  • What is ChatGPT?
  • Agile Performance Engineering
  • What is Cybersecurity?
  • Software Security Threats: A Comprehensive Guide
  • What is Software Security?

Popular Posts

Best Software Books of All Time
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future