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

Identifying the Software Vulnerabilities that Matter to You
Most articles suggest finding the weaknesses (CWE) that matter to your applications. For example, SQL injection might not matter to you if you don't use a database. So that fact that SQL injection is #2 on the Top 25, you can drop it off your list. Once you identify the weaknesses that matter to you, reduce the list by those that are in scope for the software language you are using. For example, buffer overruns in Java are not an issue anymore. Next, identify the relevant attack patterns (CAPAC). At this point your list of concerns has been whittled down.

Session 2: Predicting Software Quality Early in the Software Development Lifecycle and Producing Secure Software
The culture in software vendors today is to "Do now, fix later." Oddly enough, that has great parallels to the Agile model. At The Product Company, we use the Agile model. I'm sure it is possible to get this to work but documentation is not consistently produced and design reviews are infrequent. I'm wary of adding too many much needed checkpoints too quickly though software quality not just from a security perspective is an area gaining increasing attention.

I describe it best with this visual-evoking analogy
We often rush to get a hot new luxery vehicle with touchscreen panels, heated AND cooled leather seats, moonroof, chrome tipped exhaust pipe, 17" rims, spoiler, out quickly onto the market. But if the car explodes whenever you drive faster than 20 mph, that's a problem.
By the way, if you know me, I love analogies. In a future post when I talk about accountability, I'll use the analogy of a firing squad.

Measuring Quality with Troop Support
Measuring quality is a great challenge (but of course, since it is a metric). We will end up measuring quality by software module or component. Oftentimes, these are led by dedicated teams. To help drive accountability into these teams, get the module owners to measure quality themselves. That reduces the feeling of The Machine that just makes numbers up and hence reduces a sense of ownership. It also helps to kick-off a life cycle by having the stakeholders (business analysts that write the requirements) meet the developers. Furthermore, have your security analysts shadow a business analyst around for a week. It helps understand the context of the business issue since it is natural to work in isolation. We have to constantly work at seeing the big picture.

Lifetime Warranty
The session leader, Girish, made a great suggestion. Software development shops (where all they do is code for other customers) should consider providing a lifetime warranty on software. It's not like it wears out. I'll plan to get this one written into our future contracts at The Product Company.

Defect Creation and Project Management Concepts
As a person with a background in Project Management, I am all too familiar with the concepts of schedule compression and adding resources. What customers, which can include your boss, might not know is how that impacts the creation of defects. It's very clear if it takes you 10 hours to do something and someone wants the same thing done in 8 hours, something's got to go. But what if it takes you 10 hours to do something, someone wants it in 8 hours, but gives you twice the number of resources! Yes, you'll still get it done but probably with even more defects than if you did the same job with the original number of people in 10 hours. In software development, even if it is virtual products being created, there can still be too many cooks in the kitchen.

So what do we do? Girish introduced a term that will soon enter my regular sayings -- "Negotiated Commitments."
Developers should learn to say, "I understand your requirements, I will do my utmost to meet it, but until I make a plan, I can not responsibly commit to a date."

And Managers should learn to say, "I trust you to create an aggressive and realistic plan, I will review the plan, but I will not commit you to a date that you can not meet."

This all works as long as both sides trust each other. Developers need to understand the urgency of the issue at hand (so getting the big picture, meeting the business analysts will help). At The Mortgage Company, I had a developer that I could not trust because he would provide crazy long estimates. To counter that, I had him break each element of work into very small pieces and provide best, average, and worst case estimates. Then I would review it, make my notes, and sit down together with him to walk through them. If I did not agree with his estimate, I would explain the requirement (in case he thought there was more) and we would agree on an effort estimate. The idea is I would never just decide the time for the developers. I always want them to come up with their own Negotiated Commitment since humans, typically, would stick close to it. They don't feel like they are controlled by The Machine.

At the end of the day, unhappy people do not do quality work. Any processes and checkpoints that security introduces has to make their lives happier.

Session 3: Federal/Government Focused Panel
I didn't find this panel to be particularly useful. So no pearls of wisdom to relay here.

Session 4: Security’s KPIs – Measuring a Successful Web Application Security Program
Of all the sessions, the slides and the delivery were the best. It was delivered by a security evangelist from HP.

More to come on this in a forthcoming Part 3.

No comments:

Post a Comment