ComputerWorld is running an article from Paul Ferguson of TrendMicro claiming that there is a massive hack going on as you read this - via the phpBB bulletin-board software.  Truth be told, phpBB has been known to be bug-ridden over the years (simply Google "phpBB vulnerability" and you'll get more than you wanted) but I believe that these have come to a boiling point now.  If it's actually true, the number of site that was hacked stands at ~500,000, it would point to a massive problem within phpBB's code which likley hasn't been disclosed yet.

What worries me is not that these sites are being hacked (because this is a "normal" occurrence these days) but that they're increasingly effective.  While a half-million web sites being broken into isn't something to sound the alarm over - and this is truly a sad commentary on the state of web security today - the precision and effectiveness of these types of attacks is scary.  Furthermore, the "drive-by" installations of malware, trojans and other unwanted stuff on your computer is the stuff that security managers worry about at night.  Just think of the amount of data that a half-million key loggers can pull?  Think of the potential fallout of having to re-load (because cleaning isn't possible most of the time) every machine at your office... the possibility boggles the mind.

What comes out in incidents like this, and sadly people still do not understand, is that an insecure web application/site does more than just possibly damage the host.  A vulnerable site leaves its visitors vulnerable, which sets off a chain of reactions that resonates back into the CISO's office at any company that allows its users to browse the Internet.  More on this in a future post.

While I know it's rather un-common to have a php-facing application like this in an entierprise - it's definitely not impossible so I felt like I needed to notify and warn you readers.  More as information comes in... if it comes in.

Static code analysis failures are costing enterprises money and reputation.

White-box security testing is inherently a flawed proposition for many reasons -but it all comes down to a very simple concept:

  Machines do not execute source code, they execute machine code (compiled code). --Paul Anderson (GrammaTech)

  If you think this through for a minute you realize that there are a few specific reasons why the above statement fundamentally changes the way that people look at white-box testing, and why this is a losing proposition.  Let's analyze this in the context of a web application project for a mythical online bank.  Consider that the use-case here is that we are dealing with a bank that has an online presence (currently being analyzed) which will be integrated with a series of existing legacy applications, partners, and external 3rd party components.  Given this information let's analyze why white-box analysis (or static source-code analysis) is doomed to fail this project with respect to security.

• Compiler Optimizers Break Things - Think of it this way, compilers are designed to make machine code from your source code.  That compiler's sole purpose (in most cases) is to create machine code that will be optimized, extremely fast-executing, but not necessarily secure.  Often times security functions that people build into source code can be removed by compiler optimizers and most often without our knowledge.  These actions often undo many of the advanced security features that developers may consciously insert into their code.  Consider the following example:
• Developer is paranoid about data-persistence in memory space, and wants to be doubly-sure that variables are expired and destroyed
• Developer writes a routine whereby the variable will have a null value written to it before the memory is freed
• Compiler optimizer sees this as a double-work scenario, and removes the null-value portion and simply opts to free memory
• A potential security vulnerability is created with variable persistence in freed memory space

This example ideally demonstrates how a security vulnerability can be inserted in spite of the developer's best efforts to write secure code.  Standard static-code analysis tools which are used to "scan code" at the static-file level will fail to catch this vulnerability.  Quite simply - static code analysis fails if it is not supplemented with dynamic analysis.

• 3rd Party Library Integrations - There is another threat to developing and scanning static code in a white-box format.  Inevitably, 3rd party libraries are used to complement features or functionality that are not natively provided by the local development effort.  After all, no one re-invents the whole wheel everytime - we simply build what we cannot reuse from someone else's work, then use the publicly available libraries from 3rd parties to fill in the functionality and features that have already been written and (hopefully) tested before.  White-box testing (or static code analysis) will absolutely fail in finding flaws when it comes to pulling in 3rd party libraries.  By the definition of this type of issue, 3rd party libraries rarely provide you the source to be scanned and checked for weaknesses that will affect your application.  What you're left with is someone else's code (in machine-compiled format!) which will be interacting with your application.  Would you trust that model?
• Static Code Analysis Rarely Understands Data-Flow Modeling (Data Tracing) - If you're scanning your application with a source-code-only analysis tool, you're going to not only miss things that will almost certainly come back to haunt you - but you may also be over-working yourself without a real purpose.  Consider the following example to illustrate my point.  Before I get into that example though, allow me to explain this idea of "data-flow modeling" for those that are not familiar with this idea.Data-flow modeling seeks to understand how data moves through your application, not just how the application code is written.  After all, that's the whole pointn of the application, to work with data.  Vulnerabilities lie in manipulating data either to or from the end users or the server(s).  Data-flow modeling maps out the data in your appliaction from it's instantiation (maybe when the user types it in) to its resting state (maybe when it's finally written to a database, or handed off to another application or service for additional work).  That being said let's consider a web application that has 1,000 forms across 100 pages written in the language of your choice, built to be AJAX.  While each page does nothing individually to validate user input (the data source) all variables (data) are filtered through a central validation module deep within the application logic.  A standard source-code analysis tool (I have evaluated this and can honestly say this is a real use-case but will not mention the tool) will flag on each and every input that is not validated (within the page) as vulnerable to hudreds of vulnerabilities ranging from XSS (Cross-Site Scripting) to SQL Injection and other attack types.  What you are left with is a very lengthy report with hundreds of critical and high vulnerabilities that you now obviously must address... unless you do some dynamic analysis on the code and realize that *none* of those theoretical vulnerabilities are exploitable due to the fact that the application filters all data through the central validator/scrubber.

So, there you have it.  Static code analysis is inherently doomed to fail.  White-box testing of source-only is flawed.  The sky is falling, global warming will kill us all.  In my next installment of this column, I'll give you what you need to know to avoid failing in your security initiatives at the development step of the SDLC - remember, knowing is half the battle.

 Stay tuned!

If this information disturbs you, and you would like to talk about it directly please don't hesitate to email me directly.  I am not a sensationalist, and pride myself on presenting practical solutions to real-world problems which are realistically attainable.  Thanks for reading.

  It's a classic problem of which came first... the chicken or the egg?  politics or corruption?  security or compliance?  While I admit, it's not such a strange thing to see the two groups working together these days... I would like to point of some of the issues that I've come across between these two very important groups in today's enterprises.

  The issue of compliance is much like the issue of legal counsel.  All large enterprises, and even most small business have someone that's responsible for compliance - occasionally you'll see an entire department dedicated to the daunting task of keeping up with regulations, compliance policies, and the ever-changing landscape of procedural accountability.  Oddly enough, there is not a one-to-one relationship between the compliance department and a security department.  I've spent a large portion of my IT career in situations just like this and I would like to share some of my understanding with you.

  Compliance, while not always a necessity in private businesses, is almost always present in larger, pubilc enterprises.  The compliance department is responsible for making sure the business is in-line with self-imposed corporate regulations and policies, industry-consortium regulatory guidance, government oversight and policy even international laws too!  It's amazing these groups can even keep this stuff straight, right?  What's equally amazing is how often compliance relies on IT Security for guidance and implementation of compliance components. This of course begs the question - would IT Security exist in some organizations if there was no compliance stipulation for such groups?  On the flipside of that... in a perfectly secure world where no one is ever malicious - what would be the need for the compliance group?  So while it may be a stretch to say that one group cannot function properly without the other (I will concede that they can, albeit poorly) each is heavily dependant on the other for its very existence within a business.  This is where I find some strange... interactions.

  As I've stated, the security team often carries out part of compliance policy or regulations; or performs audits to ensure that the same regulations are being followed - but I feel like even in these cases the synergies between these groups are under-utilized.  I can't count the number of times I've been turned down for an IT Security initiative (which made perfect business sense, by the way - but was simply under-funded) only to push that same initiative through under the guise of a compliance regulation - through the compliance team.  In return... the compliance teams I've had the pleasure to work with have repeatedly called upon my security resources to be the "muscle" behind their policies.

  As I travel and talk to different groups about Application Security, I am agaff at the number of times that I get an entirely blank stare when I try to explain how leveraging compliance is a sure-fire way to get security initiatives done.  Here's my reasoning... see if you disagree...

• Compliance is a "necessary evil" which exists to keep the business in good legal and regulatory standing
• IT Security exists to keep the balance of risk/reward within the business IT as balanced as possible
• IT Security should be looking to enact initiatives which work to support the business

  If you take all 3 points above as truth (and I firmly believe they are) then it's a logical next-step to say that IT Security initiatives and Compliance initiatives will greatly overlap.  An overlap within two very necessary units of the enterprise will always, without fail, lend more credibility to their efforts and causes.  If both the security and compliance teams are pushing the same agenda, it becomes very difficult for a business owner to simply dismiss that agenda as unnecessary or frivolous.

  So a lesson-learned here - if you're not already doing this... here are some very simple yet extremely effective (based on personal experience and first-hand accounts) techniques for getting things "done".

• Open a regular dialogue with your complaince team.  Meet once a quarter, once a month, or once a week as permissable to discuss what you're independently working on
• Find overlaps in your goals from a non-technical perspective
• Create a joint strategy for compliance and technical implementation of initiatives previously agreed upon
• Review business requirements jointly - ensure that both groups understand each other's point-of-view

Given these very simple, and probably obvious, steps - I can virtually guarantee a more successful IT Security goal achievement.  You'll work less uphill, you'll "win" more often, and you'll do a much better job not only understanding but supporting your business - that makes everyone happy.

For those of you who keep up with the PCI DSS standard, the coucil today has issued an update titled: Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified.

  The standard item 6.6 has been further clarified in one of two options, as before, being either Application Code Reviews or an Application Firewall.  I'll address the first option, since that is the more logical one, but will briefly talk about the Application Firewall as well - just to clear the air a bit.  While the Standards Council continues to add clarification, which makes the standard more usable, more opportunities for compliance surface with less cost and effort.  No doubt the IT manager feels like this is a good thing because now the cost of compliance won't necessarily be astronomical - and thereby make it viable.  As we all know, the issue of compliance to a non-government regulation is always a balancing act.  Compliance, as with most security components, is an equation balancing risk against spending and business value.  We all know the results... if the equation balances just right, the business benefits from the added security and sees value while not spending more money than the risk is worth - and security feels worthwhile because risk has been decreased by some factor which affects the business in a positive manner.  Granted, it doesn't always work out quite so rosy - but the PCI DSS standard is going a long way to make sure that these equations that happen every day, in many businesses throughout the world - balance.

  Now - on to the meat of the standards update.  First off, let me address the Web Application Firewall issue.  While this is a topic that deserves a whole article onto itself, the short version is this - web app firewalls are very expensive, complex band-aids.  That's the reality.  While many of them work phenomenally well, and in fact I can name a few that do, they are difficult to implement into an existing production environment, they are primarily signature-based (remember how well we stop "unknown" viruses?), or have some other architectural quirk that makes them an impossibility in your enterprise.  Personally, at my previous company I started to implement a particular WAF ... but it took over a year and a half of research, testing, approvals, and more testing to get them into a newly built environment... not even into a legacy production environment where they would have provided the most value.  Anyway... the point is - a WAF is a tool you use when you don't have the resources to "do it right"... fix the code itself.

  Section 6.6 of the PCI DSS standards, option 1 (the Application Code Reviews) now has 4 basic alternatives.  Candidates are urged to implement at least one of the following...

• Manual review of application source code
• Propse use of automated application source code analyzer tools (static code scanners)
• Manual web application security vulnerability assessment
• Propse use of automated web application security vulnerability assessment tools

  First, a few things of note.  The above does not necessarily call for a "penetration test" which exploits vulnerabilities by an ethical hacker... only an "assessment" (which identifies but does not exploit) vulnerabilities is required.  The distincion is important because it means that you can now do this on production code, or a production environment without the risk of damaging your applications by necessity to prove their vulnerability.

  I find it interesting that the update goes and directly says "In all cases, the individual(s) must have the proper skills and experience to understand the source code and/or web application, know how to evaluate each for vulnerabilities, and understand the findings".  The fact that the DSS requirement 6.6 now specifically addresses competence in the assessor should mean that there was some ... question... over the competence of assessors or possibly a need to specifically stamp out that only qualified people should be doing assessments.  Interesting, at either angle.  The same statement goes for assessors using automated tools - but now we have an interesting proposition.  Do you (a) hire an extremely qualified application vulnerability tester, or (b) hire a knowledgeable user, and give him a software testing/scanning tool and some training... and are those even the same?  Obviously the dollar amounts for the two are different... or are they?  There is also the point about the testers having to be (the authors use the word "should be") organizationally separate from those writing the code... well that makes sense.  No one wants the fox guarding the hen-house, right?  You don't want the same developers that are potentially churning out insecure code to then review it and give themselves gold stars.  So far so good.

  So now we have 2 options for doing this internally - which will help our bottom line (external 3rd parties are typically very, very expensive)...

1. First option is to do an SDLC-integrated code review... actually reviewing the application code before it gets compiled and leaves the development group's control.  We have the option to do it manually, or with some tools - using only highly trained and knowledgeable people.
2. Second option is to do a post-development analysis of the code.  Once the code is written, built, and tested for usability issues it's time to security-test it with, again, either a human being, or some black-box testing tool(s) - but again, you must use trained and knowledgeable people here as well.

  Well, if I'm a security manager...this is great!  Thinking logically - you always want the security expertise in-house, and why in the world wouldn't you want to do application security throughout the application lifecycle?  The DSS update also goes on to remind us of requirement 6.3, and the need to have an effective change-control process such that the security reviews are not bypassed, at any level.  While the final sign-off must be done when the code is ready for production - it's imperative that the effectiveness of the application security policy be enacted to push as far back into the development (pre-development planning?  requirements gathering?) lifecycle as possible (more on that in a separate article).

  As a final note - the update talks about the need to stay current and abreast of new developments in application security testing.  It's essential that whatever tools are purchased (whether they be the full SDLC suite from HP/ASC, or some other vendor) - that these tools and their users be continually updated from the brightest minds in the field.  This is unfortunately a one-up battle against the "bad guys"... if you're behind you're sunk.

So what have we learned from the new Section 6.6 update?

• There are at least 4 ways to interpret the "Application Code Review" guideline
• You can have your code "reviewed" internally, as long as your assessor is trained and competent (but to who's qualifications?)
• You can use automated tools, either static code analysis or black-box testing software, if you have your people trained in those tools, and application security
• Your testers/assessors have to be organizationally separate from the development organization (but at what level?)
• Your organization should absolutely integrate application security as early into the SDLC as possible, using "tools and rules" in combination
• Your testers should always be up-to-date on the latest developments, techniques, and methods... otherwise you're bringing a knife to a gunbattle

Thanks for your attention!

    It's 2:34am, local time.  You're snoring up a storm after a hard day at the office.  You've patched all your servers, your lockdown scripts have been verified, and your IDS is humming along perfectly.  Oh, and by the way, someone named "R0kk1t" just stole your customer database.  A quick check of the "Security Dashboard" when you get in at 8:00am will show everything is green...  You have a serious problem.

    Sound like anyone you know?  This is a serious concern, and the problem is - it's pervasive.  It's scarry that 7 out of every 10 people I talk to about Web Application Security don't have any defenses.  When I ask what their defenses are they mention things like firewalls, IDSes, and patch policies - all have absolutely nothing to do with (and will do little for) Web Application Security.

    Houston - we have a problem.  Even if you're trying to build a program geared towards protecting your web apps - how are you going to justify it?  Inevitably someone is going to ask you the daunting question - "So, have we been attacked?  How many times?"  Odds are you're going to have no idea.  All hope is *not* lost though... I have some suggestions from years of this happening to me.  Here are some tips on building self-defense mechanisms into your web applications - and how to use them as rudimentary alerting triggers...

• Kick out the troublemakers - A well-built web application has to know when someone is just being stupid.  If your're tracking logged-in users it's even easier.  Track the per-user incidence of "bad data" and if it reaches a specific threshold - expire the session and send that user to a page warning them that they've been bad and must re-login.  It's basic, and not hard to do - but rarely implemented.  Of course, you'll have to figure out those thresholds and what "bad data" is - but at least you have a start here.
• Whitelist - In the point above I said you should track "bad data" or bad user-supplied input but how do you know what is good versus bad?  Simple, you first have to define what you should expect from the user.  An application should, on a per-page and per-input basis, know exactly what input is allowed and what data sets are in play.  You can use regular expressions to validate these lists!  For example, if you've got a field that expects social security numbers (don't we all) then you can have this simple bit of JavaScript to validate (obviously you'll want to do this on the server side!)

function isValidSSN(value) {
    var re = /^([0-6]\d{2}|7[0-6]\d|77[0-2])([ \-]?)(\d{2})\2(\d{4})$/;
    if (!re.test(value)) { return false; }
    var temp = value;
    if (value.indexOf("-") != -1) { temp = (value.split("-")).join(""); }
    if (value.indexOf(" ") != -1) { temp = (value.split(" ")).join(""); }
    if (temp.substring(0, 3) == "000") { return false; }
    if (temp.substring(3, 5) == "00") { return false; }
    if (temp.substring(5, 9) == "0000") { return false; }
    return true;
}   

• Log, Log, Log - Your web applications should always have a separate log file for "unexpected input".  In fact, where I've had input into the development process I've required there to be at least 2 log files.  First log file logs all "unexpected actions" in a web application, the time/date, the logged-in user, the source, user-agent and all other pertinent details of the "unexpected action" whether it be an exception, a crash, or whatever.  The second log file is just a dump of all the weird input people submit - some malicious, some not, to better help write regular expressions to filter the garbage.
• Fire Alerts - All the things I've mentioned previously are great - but if no one looks at them, or gets an alert when they fire - they're worthless.  Make sure you create actionable alerts from with your application framework.  Combine all the loggins, white-listing, and self-defense into something that you can understand.  Be careful of the information Monster though... if you're not careful in the way you set this up you'll end up with 10,000 emails/hour and won't be any more effective than having nothing.  It's a difficult balance but with practice you'll be one step closer.

Well - I hope you find those useful.  If you're willing to share, I would love to hear of some other methods that YOU are using in the real-world!  Leave them as a comment here, share with the community - remember we're all smarter when we share information.

    It's the words that keep IT Security Managers up at night - "We have a problem, I think we've been hacked".  Of course, there are few possible responses...

• Acknowledge Responsibly - You can acknowledge what has happened, open an investigation, and communicate with the public and your customers.  While this may be initially bad PR, in the end it shows responsibility and maturity of process and management
  
• Acknowledge Irresponsibly - You can acknowledge the issue but attempt a campaign of mis-direction and cover-up.  Redirect blame to partners, vendors and even former employees, release mis-leading information about the magnitude of the issue and do not publicly investigate the breach.
• Bury It - Re-direct blame, issue no statements or official information
  

    The problem is this - you know which you want to do, but which option will your lawyers allow you to take?  There are many IT Security departments which are run more by the company legal counsel than the IT Security manager or CISO.  Why is this you may ask?  Lack of planning and initiative.  If a CISO has no strategic, pre-planned response plan for that dark day - the lawyers will more often than not take over and try and guide the company out of trouble (and in the process create a bigger problem).  Responsible breach disclosure isn't easy to plan for, and if executed poorly will potentially cause a catastrophic end.  This game isn't for the faint of heart.

    The purpose here isn't to poke at the legal counsels, in fact, they're entirely necessary and should be your allies.  They should not; however, run your crisis management process.  Crisis management should be left up to those who are trained for it, and not to the CEOs, the lawyers, or the PR department.  Litigation should be a component of your crisis-management process but if you lose control of the situation as the "security" function - you're in for a rough ride.

    As the title of this entry suggests, there is a political component to every "incident" that must be carefully navigated.  Leave room in your response strategy (crisis management process) for all those previously mentioned folks to do their part - but make sure you understand that you have to control the situation.  You're only going to accomplish any semblance of control by planning in advance, working your plan through the ranks, and making sure you have buy-in long before the call comes.  This is really a case of failing to plan means planning to fail.

    Politics is a dirty business, but unfortunately you cannot escape it, even in IT Security management.  Remember, make allies, plan ahead, and get buy in and you'll weather the storm.  Otherwise... I need to tell you a story about 3 envelopes... 

    Over the last 8 years in IT Security, I've had at least a professional interest in the idea of penetration testing and the opinion of this service has evolved as the IT Security market niche matures and grows.  I wanted to take a minute to discuss it with the readers out there, and maybe solicit some opinions on the topic if you're willing to offer yours.  I'll reserve my personal opinion for the end, but wanted to present some thoughts, rebuttals and commentary on these here.  I'm going to address penetration testing in the context of web applications - but this can be allied virtually to any technology out there.

Let's first look at the arguments for penetration testing:

• Penetration testing provies a hackers-eye view of your web application attack surface
• Penetration testing provides an outsider's view of your web application attack surface 
• Penetration testers will often find ways to manipulate your applications in ways your developers never thought possible
• Penetration testing offers the client an opportunity to get a snapshot picture of your security posture
• A penetration test goes more in-depth than a "security scan" by identifying and exploiting real weaknesses

    Those are some compelling points, to be sure.  Security is a very strange f1sh, it changes so drastically so often it's almost impossible to be entirely up-to-date all the time, unless that is your sole job.  This is precisely what penetration testers are great at - they focus their entire energy on researching, identifying, and exploiting security weaknesses in, in this example, web applications.  There really isn't any amount of "scanning" that an automated tool can do which will match the power and adaptive capability of the human mind - I don't think anyone will argue that - so the value of employing someone who is extremely versed in this sort of thing is akin to having your transmission looked at by a transmission-only specialist... you do it because you want to go to the expert.  There are varying degrees of expertise; of course, and let's not even try and disagree that you get what you pay for.  If you want a top-notch security expert, you're likely going to be hiring someone with a shady past, and it's going to cost a lot - but at least you know you're getting the top talent matching wits with your pro-active security measures.  But what about the other side of the coin?

Let's look at arguments against penetration testing:

• Penetration testing can be argued to be a test of the 'tester' not the target
• Penetration testing isn't an exact science, and rarely standardized
• Penetration testing results are inconsistent
• Penetration testing is too expensive
• Penetration testing is only a snapshot in time

    With those arguments against penetration testing - how can one reasonably conclude it's a good idea?  Well, the fact of the matter is that penetration testing is expensive, inconsistent and rarely an exact, standardized process (unless you pick one of the top firms which have standardized).  Yes, sometimes the results are inconsistent and a mere snapshot in time, not an accurate assessment of your stategy as a whole.  The argument has also been made that a penetration test result is often a test of the "tester's" intelligence and hacking prowess, and not necessarily of the defenses... however I would say think twice about that argument.  Isn't that the point?  You hire the best, they put their mind to the test against your defenses?  So now the pros are weighed against the cons... and the money issue is always on the forefront of the decision to go one way or the other.  I will only offer you these words...Strike a balance in your strategy - but do not fail to test yourself.

    Remember, the right balance when it comes to penetration testing is in moderation.  You can't reasonably have a penetration test done once a week, as it would destroy your budget.  You also shouldn't do it once a year - as that's probably too rare.  The right balance is a combination of automated tools which you and your security team can use to self-assess plus a seasoned expert tester to check your sanity and environment.  Heed my warning... find your vulnerabilities because if you're not testing the security of your web applications - rest-assured someone else is.

It's one of those obvious things.  A defect is a defect, right?  Whether the airbag is faulty, or the gas cap doesn't hold pressure... a defect is a defect.  The strange thing is - it hasn't been that way, and still isn't that way, in most of the IT shops I've been in.  Why?

The reason is simple.  Historically, security vulnerabilities have been in a class all their own.  In an attempt to put some urgency to the matter, security professionals have labeled defects in the security of their projects (in this case I'm talking about web applications) as an entirely different thing than a functional defect.  What we didn't realize is that we were actually doing a dis-service to ourselves and the security cause.  You may not agree with me right now - but I'll explain this more clearly, and I think you'll be on board with my thought process.

Let's talk about defects, in general and then apply it to the matter at hand.  First, let's identify what a defect is...  A defect is, in the dictionary sense (cut from dictionary.com):

de·fect      /n. ˈdifɛkt, dɪˈfɛkt; v. dɪˈfɛkt/ Pronunciation Key - Show Spelled Pronunciation[n. dee-fekt, di-fekt; v. di-fekt] Pronunciation Key - Show IPA Pronunciation

OK, easy enough right?  So the first meaning is clear; a defect is a shortcoming, fault, or imperfection.  It is reasoned that a defect in a web-based application results when functionality X doesn't work as required.  Say you have a button, and the functional specification (we'll get back to this gem in a minute) calls for the button to perform some action, A.  During the testing phase of the application, before release to production, a tester or tool is utilized to test the functionality of that button, but instead of action A happening, some other action B happens.  This is a defect.  There is no doubt in anyone's mind that this immediately gets classified as a defect, put into the defect tracking system and sent back to the developer for remediation.  The defect is classified as a higher-priority defect if the function happens to be one that is showcased, or important to the overall functionality of the application.  Those of you that already use the HP Quality Center tools know exactly what I'm talking about, and know how this process works.  Here's the strange twist though - why is quality testing only done with good data?  I understand that you want to make sure that the test cases work properly - but why are the testing options limited?  The issue at hand here is a very narrow view of defects, and defect testing.

Back in college, I took very basic programming class and had to write a program that was a calculator.  It would ask for two inputs of numbers, and then give you an option to perform either an addition, subtraction, multiplication or division of the inputs.  Generally, it was assumed that these would be numbers, but what if they weren't numbers?  Most of the students in the class, myself included, never thought about ... "What if someone enters a letter or some other unexpected input?"  Well, luckily, the professor chose my application, put it up on the screen for the whole class to see, and promptly entered a and b for the two inputs and tried to add them.  When my application core dumped, he explained to the class why I had gotten my first F on a project.  I learned a very valuable lesson that day - developers must brace their applications for unexpected input.  "Why would anyone want to enter something other than numbers?" wasn't a good enough answer to explain why my application failed.  Let's apply this lesson I learned back in college to today's application programmers and functional testers.

Here are the reasons why I think security vulnerabilities aren't seen as "defects" in general...

1. Security professionals have insisted that a vulnerability is its own separate category - While it is true, some security vulnerabilities are a whole new level of "bad" they should be considered just like any other defect in the application for the sake of tracking and remediation.  Web platform managers are generally concerned with meeting the demands of their customers and producing code that is defect-free - and it's our own fault that "vulnerabilities" of the security variety have become some ethereal, magical issue for security nerds to worry about.  This matter can only be fixed by changing the naming back... a vulnerability is a defect, period.  Security vulnerabilities must be explained as "high-criticality defects" to developers, managers and customers otherwise this situation will never change.
2. Functional specifications rarely, if ever - call for for security validation - Functional specifications aren't written by security professionals, generally.  At best, security professionals have a chance to review the functional specification way too late into the process, while the code is being written and readied for production.  This is, once again, our own fault most of the time.  The answer to this dilemma is a two-pronged attack.  We as security professionals must educate those that write functional specifications, and enlighten them to the need for security features.  At the same time, we must work hard to have an active input in the writing and release of functional specification documents.  These two vectors are critical to getting secure code as an end-product.
3. Programmers don't typically think about malicious users - While it would be great to think that one day all developers will inherently write secure code because they will have "learned" what security is, and how important it is to the application - the fact is that it's a pipe dream.  Developers care about one thing... meeting functional specifications in the least amount of time possible, and moving on to the next project.  Developers like to write optimized code that accomplishes the required tasks in as little time as possible.  Solving #2 above will also partly solve this problem.  In addition, developers must be given the tools (such as static and dynamic code analysis tools as plug-ins to their IDEs) to make their jobs easier.  It is not reasonable to expect developers to be security experts in all aspects, so we must arm them with the tools to be experts, without having to do too much extra work or they won't use those tools.

So what have we learned today?

• Security vulnerabilities must be re-classified as easily-understandable "functional defects"
• Funcitonal specifications must be written to include provisions for security validation
• Quality professionals must be given the tools to test for "security defects" in web applications to close the loop in the lifecycle
• Developers must be educated and also given the tools to write more secure code with minimal additional effort

-- I welcome your comments!

  First, let me say thanks for clicking and taking a minute to read my column.  I hope to keep your attention while teaching you something you hopefully already don't know so come back often, bookmark me, or feed it into your RSS reader.

   Let me use this first article to explain the types of content you'll find in this column, and some of my thought process when choosing what to write.  My column typically includes the following:

• High-level discussions of security topics relevant in today's world - too many times the small stories are the big news and they don't get enough coverage
• Semi-technical pieces on important issues which you should care about - it's a shame how the message of an article can get lost in the technical details.  Not everyone reads in binary and I understand that, and write my column accordingly.
• In-depth analysis of specific headline-grabbing issues with a not-just-for-nerds spin - We'll take deeper dives into topics which grab the headlines with technical talk, explanations, and as always the "Why you should care" section.
• Articles relevant to the business manager, the executive, and the aspiring CISO - Have you noticed how few columns there are written in an intelligent, technical and business-relevant way that you the manager can read and understand?

  You, my readers, are always invited to reply with your opinions, thoughts, and debate.  I thik a one-sided conversation is boring so I welcome your replies.  My only request is that you keep your comments and replies professional and work-safe; this is, after all, a column you would share with your manager.

  As a final disclaimer, the thoughts, opinions, and views shared here are my own - not anyone else's.  If you don't agree - write a rebuttal.  If you don't like it, don't read it.

 Thanks, I look forward to having you as a regular!