Friday, December 3, 2010

Managing Expectations for Security

Whether you are leading a new security program or leading an existing one that left many with sour memories, or worse both, Management may have a perception that you are a heroine here to save the day. Similarly, as a security professional, we oftentimes think a product we purchase may do just that (more about this later).

Nevertheless, it is of immeasurable importance to manage expectations as early as possible, best when you broadcast the chart you course (or your Security Roadmap).

Suppose your company does not give anyone the sense that you are secure or safe. Just because you have been appointed doesn't mean the change will happen overnight, in a month, a year, or even two years. Furthermore, you need to reinforce to Management that very expectation.

Why?

Changing brand perception is one of the most difficult things any company can do. Whether it is to change a perception that this Company can perform services or products very different from what is done today. Think about the American auto industry. It was over 10 years ago that they delivered some of the worst quality products to date. However now, Ford is one of the top rated manufacturers of quality yet many Americans, previously trusting then horridly burned (some literally), are hesitant to return to Ford. Changing a brand perception takes years. Microsoft has been working on it since Windows 95 and now in Windows 2003, 2008, (let's not think about Vista), and Windows 7, they have begun to show they can help set the pace in software security (how many others have modeled their vulnerability management program using Microsoft as an example to improve upon).

If changing brand perception takes years, losing it takes only days or months (think about BP). Reputation is easy to destroy, hard to build and maintain.

Oftentimes, customers don't demand security or explicitly ask for it. They expect it. It's something they don't think about or necessarily ask for unless they are already quite aware of the need for and importance of security. Thus, it is a frivolous point to say that we don't need security because not a lot of people ask for it. Or we don't need to fix this because not a lot of people reported it. Security vulnerabilities are defects but defects are not security vulnerabilities.

These are one of many expectations that must be managed and concepts instilled.

Thursday, November 4, 2010

SecureSDLC - Building Security into the Software Lifecycle Part 2

Event Agenda
This was a well-run and well-attended event considering it was free for ISC2 members. Surprisingly, ISC2 provided refreshments and bagged lunch (or perhaps it comes free when you rent a space in the Ronald Reagan Center in DC). One of the last two session leads had a personal issue and was not able to make it. I'm not sure which since I had to leave after session 4.

Highlights of the Day

Session 1: Avoiding the Most Dangerous Software Security Weaknesses – the 2010 Top 25
As I had mentioned in a previous post, I was interested in hearing this session. While the seminar description alluded to how it might discuss security in contract language, it was only discussed in about 30 seconds. Essentially, it is heavily forthcoming from customers at least a line in contracts or RFPs that ask how a software vendor handles the Top 25 vulnerabilities.

Security Products that use CWE
The session lead, Robert Martin, described his experience in working with the major security software vendors in getting their input for the CWE and getting them to use CWE content in their products (static and dynamic security scanners). In doing this, he discovered that application security scanners don't have much in common. While they all scan for cross-site scripting and SQL Injection well, they do not have much overlap. This is consistent with what I described in an earlier post where each aspect of security testing is only able to detect a portion of the total population of vulnerabilities. We all laughed that perhaps they shouldn't call each other competitors since that would imply they have almost the same products. I would like to see some test report on what each major software vendor was able to find - I suppose that would be much like a Gartner Magic Quadrant report but I would like to see the test results since what Gartner says is a leader doesn't mean it will work for you since your applications may need focus on other vulnerabilities. Nevertheless, it would be worthwhile to use multiple tools.

CWE Compatibility List

Cross-site scripting (XSS) and SQL injection - battle for #1

XSS beats our SQL injection as top vulnerability of this era in web application security because there are 17 ways to attack it while SQL injection has 5 different ways (as of this post). Furthermore, XSS is more difficult to fix since there are so many different entry points and a larger attack surface.

XSS Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.5)
232Exploitation of Privilege/Trust
85Client Network Footprinting (using AJAX/XSS)
86Embedding Script (XSS ) in HTTP Headers
32Embedding Scripts in HTTP Query Strings
18Embedding Scripts in Nonscript Elements
19Embedding Scripts within Scripts
63Simple Script Injection
91XSS in IMG Tags
106Cross Site Scripting through Log Files
198Cross-Site Scripting in Error Pages
199Cross-Site Scripting Using Alternate Syntax
209Cross-Site Scripting Using MIME Type Mismatch
243Cross-Site Scripting in Attributes
244Cross-Site Scripting via Encoded URI Schemes
245Cross-Site Scripting Using Doubled Characters, e.g. %3C%3Cscript
246Cross-Site Scripting Using Flash
247Cross-Site Scripting with Masking through Invalid Characters in Identifiers

SQL Injection Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.5)
7Blind SQL Injection
66SQL Injection
108Command Line Execution through SQL Injection
109Object Relational Mapping Injection
110SQL Injection through SOAP Parameter Tampering

Wednesday, November 3, 2010

SecureSDLC - Building Security into the Software Lifecycle

I will be at the SecureSDLC in Washington, DC tomorrow.

Software professionals need the latest tools and information to ensure that software is being built with security in mind starting with the requirements phase.

This program will arm those stakeholders involved with the planning, development, design, coding and deploying of applications about the need for secure software, what should be considered in securing each phase of the software lifecycle and how organizations can create their own software assurance program. Additionally, there will be a look at the regulatory landscape and what professionals need to be aware of concerning this.

Session: Avoiding the Most Dangerous Software Security Weaknesses – the 2010 Top 25
Hosted by MITRE, I'm particularly interested in attending this session. The session description suggests it will talk about application security requirements in procurement contracts. Back at The Mortgage Company, we would often have detailed security requirements and test criteria for any procured software. At The Product Company, I anticipate our customers will soon delineate these and see what the industry de facto due-care is.

Session: Security’s KPIs – Measuring a Successful Web Application Security Program
Hosted by HP. I'm wary of this session since most security conferences that cover KPI's or metrics often leave much to be desired. I hope this one will be different. Just give us something to react to!

I wish they would cover
Embedding secure activities into an Agile life cycle. Microsoft wrote about this but I'd like to hear a talk about it since as I understand it, this may be a contentious issue and I'd like to hear it presented by someone who has gone through it.

The Marathon

This past weekend I ran a marathon. I tirelessly did so (for the second time) like I was carrying a 50 lb sack up a hill (saying courtesy of The Mortgage Company).

Today, for The Product Company, I had to expeditiously release a communication. Our lawyers suggested an edit where the security team would work "tirelessly" to resolve issues. It made me think not only of the mental exhaustion to put the communication together, but also the physical exhaustion still lingering from the marathon. I quipped - "How about diligently? Tirelessly makes me feel abused and exhausted." Not sure if it was as amusing to anyone else but we ended up with:

Whether publicly or privately communicated, we will work diligently to ensure that any confirmed vulnerabilities are addressed.

Screenshot of Marathon Time Projector Spreadsheet
Nevertheless, if you want to project your marathon time, I created a handy Excel spreadsheet. You can adjust your mile-by-mile pace, project your finish time, project your mile-by-mile time, and more! I protected the spreadsheet (thus locking the cells) without a password only so it is clear you only need to edit the fields highlighted in yellow.

Link to the greatest Marathon Time Projector spreadsheet

Friday, October 1, 2010

Types of Software Security Testing

Mature software security testing activities combine multiple security testing perspectives. Each type yields differing results since no tool can identify the full population of issues. Combined, a more complete picture can be obtained.


Static Application Security Testing (SAST)
Scans at the source code level

Static analysis tools are good, but not perfect. Like other forms of testing, they only look for a set of rules in the source code. They can quickly find common security vulnerabilities.


Binary Code Analysis
Analysis at the byte-code level

What is written in the source code is not necessarily what is executed. For example, compilation optimizers may remove various lines of code that appear to never being called. Thus, static code analysis will fail to detect certain vulnerabilities. 


Dynamic Application Security Testing (DAST)
Analysis at run-time, simulates production usage

Analyzes applications in its running state to help automate basic penetration testing.  Essentially, it traverses the application and simulates what attackers may do.

Example tools: