Archive for the ‘security’ Category

Reference – Security Bug Assessment Model – STRIDE

Saturday, March 24th, 2012

Before the current focus on security at Microsoft, all security bugs at Microsoft were rated using the DREAD model. (See prior post). Now, Microsoft rates each security bug using the STRIDE model. STRIDE is an acronym that stands for:

  • Spoofing
  • Tampering
  • Repudiation
  • Information Discovery
  • Denial of Service (DoS)
  • Elevation of Privilege (EoP)

 

Reference – Security Bug Assessment Model – DREAD

Saturday, March 10th, 2012

Before the current focus on security at Microsoft, all security bugs at Microsoft were rated using the DREAD model. DREAD is an acronym stands for:

  • Damage Potential
  • Reproducibility
  • Exploitability
  • Affected Users
  • Discoverability

When a bug was filed, the bug would be rated from 1-10 in each of these areas.

 

Security Reference: CIA Triad

Saturday, October 22nd, 2011

In security parlance, the following 3 points make up the "CIA Triad":

  • Confidentiality
  • Integrity
  • Availability

The Wikipedia article on the CIA Triad describes confidentiality in this context as "prevent the disclosure of information to unauthorized individuals or systems"; integrity as "data cannot be modified without authorization"; and availability is described as when the information can be accessed.

Two Cross Site Scripting Cheat Sheets

Saturday, April 30th, 2011

I love cheat sheets. They jog my memory about things I need to do or should test for – especially when I have not done it for awhile.

From a test perspective, my favorite test value cheat sheet for cross site scripting (XSS) is http://ha.ckers.org/xss.html. If you have not tried out these samples (and variations on the themes) in your own web application, you need to do it now.

From a developer perspective, OWASP’s (Open Web Application Security Project) XSS (Cross Site Scripting) Prevention Cheat Sheet provides a set of rules to implement.

 

The Power of Ten – Rules for Developing Safety Critical Code

Saturday, January 29th, 2011

I was reading an article when I saw a reference to how NASA’s Jet Propulsion Laboratory (JPL) was using 10 simple coding guideline to develop safe code. The article referenced the following URL: http://spinroot.com/p10/. Going to this site, you will discover that the work was originally published in the June 2006 issue of IEEE Computer in The Power of Ten – Rules for Developing Safety Critical Code by Gerard J. Holzmann.

The paper and site describes 10 rules:

  1. Restrict to simple control flow constructs.
  2. Give all loops a fixed upper-bound.
  3. Do not use dynamic memory allocation after initialization.
  4. Limit functions to no more than 60 lines of text.
  5. Use minimally two assertions per function on average.
  6. Declare data objects at the smallest possible level of scope.
  7. Check the return value of non-void functions, and check the validity of function parameters.
  8. Limit the use of the preprocessor to file inclusion and simple macros.
  9. Limit the use of pointers. Use no more than two levels of dereferencing per expression.
  10. Compile with all warnings enabled, and use one or more source code analyzers.

Check the site and the paper out.

 

New Security Paradigms Workshop

Saturday, December 18th, 2010

I was listening to Security Now 229: The Rational Rejection of Security Advice when there was a reference to site/conference that I found intriguing. The entire episode was based on a paper from the conference.

The site, www.nspw.org, is the companion to the "New Security Paradigms Workshop" events. The description of the workshop is what I find so fascinating:

The New Security Paradigms Workshop (NSPW) is an annual, small invitation-only workshop for researchers in information security and related disciplines. NSPW’s focus is on work that challenges the dominant approaches and perspectives in computer security. In the past, such challenges have taken the form of critiques of existing practice as well as novel, sometimes controversial, and often immature approaches to defending computer systems. By providing a forum for important security research that isn’t suitable for mainstream security venues, NSPW aims to foster paradigm shifts in information security.

It happens that all of the proceedings for the conference are available online. Well worth reviewing.

 

Common Weakness Enumeration (CWE)

Saturday, December 11th, 2010

I was reading a press release for a security analysis program and there was a reference to the "Common Weakness Enumeration site". I was not interested in the product but did decide to investigate the site referenced.

The Common Weakness Enumeration (CWA) is subtitled "A Community-Developed Dictionary of Software Weakness Types." The site is hosted by MITRE”. The scope of the project is to "provides a unified, measurable set of software weaknesses."

It appears that the starting point of this taxonomy of software security weaknesses was quite a few of disparate standards, papers, proposals, etc. A pretty good list and links to original sources can be found on the sources page. Each item in the list includes a description, where the weakness may be introduced, whether it is applicable to particular platforms, examples and related items.

 

Cyber Security Links from March 2010 SW Engineering Notes

Sunday, July 25th, 2010

The following links were published in the March 2010 ACM SIGSOFT Software Engineering Notes in the "Surfing the Net for Software Engineering Notes" by Mark Doernhoefer. This issues topic was Cyber Security.

 

Douglas Crockford – Quality

Saturday, July 17th, 2010

A coworker pointed me to the following video: Quality Software Development by Yahoo Architect Douglas Crockford (181 MB). The presentation from from the Yahoo 2007 FrontEnd Engineering Summit (March 7-8, 2007).

Below are my notes of the slide titles.

  • The Software Crisis
  • Craft vs Engineering
  • Computer Science has not taught us how to manage software projects
  • Software Construction (Good and Bad Analogy)
  • Nature of Software
  • Programming is Difficult
  • Lack of Metrics
  • Lines of Code – not good
  • Programmers are optimists
  • Programmers do not understand how they spend their time
  • Actual time typing is pretty small
  • Skeptical of anything that requires more keystrokes
  • Programming is a social activity
  • Cost of Innovation
  • Legacy
  • Leaps (of productivity? software capability?)
  • Object Oriented Programming (History)
  • Failed Leaps
  • Software does not have enough self awareness to be afraid of bugs
  • Bugs
  • Snake Oil / Silver Bullets
  • Mythical Man Month (1975)
  • Literate Programming (Knuth)
  • Significant difference in individual ability
  • Surgical Team (Harlan Mills)
  • Incrementalism
  • Beta (Perpetually Unfinished)
  • Application triad (skill, technology, requirements)
  • Feature Cost
  • Code Value
  • Code Quality (Micro and Macro View)
  • Simplest thing to enhance value of codebase – make more readable
  • Yahoo Javascript coding convention
  • Programs are a medium of intentional communications
  • Good architecture – necessary structure to keep from collapsing
  • How do we change a correct program into another correct program?
  • Cruft – “Software Scar Tissue”
  • Causes of Cruft
  • Bloat – “Software Cancer”
  • Insecurity
  • Cruft accumulates -> complexity groups -> progress slows
  • Refactoring
  • Sometimes it is best to start over
  • The pain of the crash
  • The illusion of completion
  • An experienced team can cross that ground again very quickly
  • Conclusion

 

2010 CWE/SANS Top 25 Most Dangerous Programming Errors

Saturday, February 27th, 2010

The 2010 CWE (Common Weakness Enumeration) / SANS Top 25 Most Dangerous Programming Errors has been released. The full report should be required reading for all web programmers and testers. A pdf version is also available.

Here are the 25 items:

  1. Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
  2. Improper Sanitization of Special Elements used in an SQL Command (‘SQL Injection’)
  3. Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)
  4. Cross-Site Request Forgery (CSRF)
  5. Improper Access Control (Authorization)
  6. Reliance on Untrusted Inputs in a Security Decision
  7. Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
  8. Unrestricted Upload of File with Dangerous Type
  9. Improper Sanitization of Special Elements used in an OS Command (‘OS Command Injection’)
  10. Missing Encryption of Sensitive Data
  11. Use of Hard-coded Credentials
  12. Buffer Access with Incorrect Length Value
  13. Improper Control of Filename for Include/Require Statement in PHP Program (‘PHP File Inclusion’)
  14. Improper Validation of Array Index
  15. Improper Check for Unusual or Exceptional Conditions
  16. Information Exposure Through an Error Message
  17. Integer Overflow or Wraparound
  18. Incorrect Calculation of Buffer Size
  19. Missing Authentication for Critical Function
  20. Download of Code Without Integrity Check
  21. Incorrect Permission Assignment for Critical Resource
  22. Allocation of Resources Without Limits or Throttling
  23. URL Redirection to Untrusted Site (‘Open Redirect’)
  24. Use of a Broken or Risky Cryptographic Algorithm
  25. Race Condition